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w  *  ^cVor-  , _ , 

^  ^  y  WESSON  21  ^  SYSTEMS  ACQUISITION  ^ 

"T  --3 

Well,  we're  glad  ^Kat  you  decided  to  experience  the  second  half  of 
this  course.  We  hope  Is  a  sign  that,  like  I.  M.  Eager,  you  have  gained 
an  awareness  and  appreciation  of  the  overall  human  factors  engineering 
procesV*  While  I.  M.  suffered  through  the  trauma  of  designing  his  super 
helicopter,  we  were  £ble  to  sit  back  and  profit  by  hls/'experiences. 

It  lsXgood  to  dee  that,  like  our  hero,  you  have /decided  to  learn  more. 
Eager  felt  h|iat  he  ras  lucky  to  have  enrolled  in  p/ofessor  Ed  U.  Kator's 
applied  HFE  course,  and  we  bet  that  you  decided  kmg  ago  that  you  needed  to 
learn  just  how  Nall  tne  HFE  puzzle  pieces  fit  together.  For  the  remainder  of 
this  course,  **wdyl"g  the  big  picture  of  systems  acquisition  as 

~~#ell  as  the  specific  contributions  made  by  tnr^FE) community  to  the  acqui¬ 
sition  process.  Enough  of  the  preliminaries.  Let's  go  on  Into  the  classroom 
where  Professor  Kator  Is  about  to  start  his  introductory  lecture  concerning 
systems  acquisition.  Figure  21.1  In  your  supplement  will  be  useful  to  you 
during  the  course  of  the  lesson.  Figure  21.1  goes  beyond  the  practical 
questions  tbat/  a  HFE  specialist  might  ask. 

The  varied  routes  and  myriad  details  of  how  the  Federal  government 
goes  about  procuring  material  is  a  complex  subject  that  Is  well  beyond  the 
scope  of  our  course.  Department  of  Defense  acquisition  activities  may  in¬ 
clude  anything  from  direct  procurement  of  corn  flakes  packaged  to  stay 
crisp  In  the  tropics,  to  the  development  of  major  weapons  systems,  such  as 
missiles,  warships,  and  planes,  and  each  potential  acquisition  of  military 
system,  equipment,  and  facilities  may  be  subjected  to  the  human  engineering 
requirements  of  the  Military  Specification  MIL-H-46855. 

"--The  human  engineer  Is  fundamentally  concerned  with  making  sure  that 
the  best  possible  designs  are  provided  within  the  constraints  of  time, 
money,  and  technical  capability^  Cost  weighs  especially  heavy  In  the  system 
acquisition  process.  While  less  expensive  systems  may  satisfy  less  strin¬ 
gent  specifications  and  controls/  over  the  acquisition  process,  this  is  not 
always  the  case  with  HFE  requirements.  While  some  very  expensive  Items  may 
naturally  meet  stated  HFE  enter  la,  some  relatively  low  unit  cost  items 
(such  as  back-pack  carrying  frames  now  in  Army  use)  may  require  Intensive 
human  engineering  efforts.  Thus^Jhe  level  of  human  factors  input  to  sys¬ 
tems  acquisition  is  not  determined  by  the  cost  of  the  system  alone,  but  by 
the  extent  to  which  the  system  needs  to  be  human  engineered. 


k-fc  r. 


(Go  on  to  the  next  page) 
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From  Page  1 


J 


Well,  what  should  you  have  concluded  about  systems  acquisition  so  far? 

(1)  The  only  time  that  DOD  is  concerned  with  testing  and  evaluating  prod¬ 
ucts  and  systems  is  when  they  are  new  and  unique  to  military  application. 
Turn  to  Page  98. 

(2)  Existing  military  standards  provide  checklists  to  follow  for  all  as¬ 
pects  of  system  acquisition.  Turn  to  Page  92. 

(3)  There  is  no  single  uniform  method  to  be  followed  in  the  DOD  acquisition 
process.  Turn  to  Page  70. 


From  Page  8 


(4)  Look  a  little  more  closely.  Two  of  these  answers  are  close  and  one  is 
way  out  of  line.  Remember,  we're  looking  for  the  instance  in  which  the  use 
of  systems  analysis  is  'most  important.'  Return  to  Page  8. 


From  Page  84 


(2)  This  is  a  true  statement,  but  not  the  answer  to  our  question.  What 
makes  this  whole  scheme  a  process  and  not  a  static  event?  Return  to  Page 
84. 
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From  Page  5 


(3)  You're  only  thinking  of  the  small  picture.  This  Is  only  one  example  of 
a  factor  which  can  influence  performance.  Think  big!!  Return  to  Page  5. 


From  Page  48 


1  (1)  Your  answer  is  Incorrect.  This  might  be  an  operational  performance  re¬ 

quirement,  but  is  it  the  best  or  only  performance  requirement?  Return  to 
Page  48 . 
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From  Page  18 


(  (3)  Sorry,  but  this  is  a  subtask  of  the  system,  not  a  function.  Try 

another  answer  on  Page  18. 
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From  Page  85 


I _ I 

(1)  Right  on,  ol'  buddy,  this  is  the  only  example  given  which  is  a  task  a 
crewperson  could  perform.  Orbiting  earth  and  flying  at  supersonic  speeds 
are  functions  required  to  achieve  the  overall  mission  of  'fly  to  the  moon' 
or  'maintain  Interstellar  peace.'  Very  good.  Keep  up  the  good  work. 

The  tasks  which  you  have  identified  should  have  three  characteristics. 
Each  should: 

(1)  Relate  directly  to  a  mission. 

(2)  Be  required  for  that  mission. 

(3)  Be  stated  in  terms  which  are  measurable. 

For  example,  the  last  answer  may  more  correctly  be  stated:  'using  the 
available  data,  the  operator  must  plot  the  flight  path  with  X  degree  of 
error.'  The  plotting  of  a  flight  path  is  directly  related  to  the  mission, 
and  is  certainly  required  of  the  mission.  Think  about  it  for  a  moment.  If 
you  had  to  determine  whether  or  not  a  math  student  had  passed  the  math 
course,  wouldn't  you  be  specifying  performance  standards?  Sure  you  would. 
Similarly,  if  you  had  to  decide  whether  or  not  the  infantry  team  had 
accomplished  its  mission,  you  would  have  some  criteria  to  use  in  making 
that  decision.  Now,  the  question  is  what  aspects  of  performance  would  you 
measure  to  develop  those  criteria?  There  are  two  attributes  of  performance 
which  are  typically  used  to  measure  human  performance.  Which  two  are  they? 

(1)  User  acceptability  and  accuracy.  Turn  to  Page  33. 

(2)  Number  of  errors  and  type  of  error  made.  Turn  to  Page  80. 

(3)  Time  to  complete  the  task  and  accuracy  of  performance.  Turn  to  Page 

22. 

(4)  Probability  of  success  and  performance  time.  Turn  to  Page  42. 


From  Page  9 


(1)  This  is  the  definition  of  a  task,  not  a  task  Inventory.  Return  to  Page 
4. 
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From  Page  16 
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(2)  Correct.  Human  factors  test  and  evaluations  are  used  to  determine 
whether  (and  to  what  level  or  standards)  each  trained  Individual  can  per¬ 
form  In  the  specified  sequence  all  the  performance  tasks  assigned  to  him  In 
a  system. 

Let's  try  another  question.  Which  of  the  following  answers  best  ex¬ 
plains  how  the  trained  Individual's  performance  could  be  influenced? 

(1)  Population  stereotypes  were  Incorporated  In  control/dlsplay  design. 
Turn  to  Page  10. 

(2)  Equipment  configurations  result  in  good  work  space  design.  Turn  to 
Page  47. 

(3)  Performance  by  other  personnel  can  Influence  the  Individual  In  the  sys¬ 
tem.  Turn  to  Page  3. 

(4)  All  of  these  are  factors  which  can  affect  performance.  Turn  to  Page 
73. 


From  Page  24 


(1)  This  sounds  good,  but  there  is  not  always  a  premium  on  longevity,  par- 
•  tlcularly  in  areas  of  rapid  technological  change.  Return  to  Page  24. 
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From  Page  29 


( 

(3)  The  'time  slice*  approach  is  a  valid  first  step  toward  identifying 
'  total  manpower  requirements,  but  it  does  not  identify  all  manpower  require- 
(  ments.  Return  to  Page  29. 
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From  Page  52 


(2)  Yea  indeed,  but  there  are  other  than  engineering  payoffs  from  fabri¬ 
cating  a  mock-up.  Defining  these  payoffs  is  a  big  step  toward  determining 
how  sophisticated  the  mock-up  should  be.  Return  to  Page  52. 


From  Page  48 


(3)  We're  afraid  you've  been  too  hasty  in  your  choice.  It's  true  that  pro¬ 
ducing  photographic  recordings  might  be  an  important  performance  require¬ 
ment,  but  there  are  other  equally  viable  answers.  Return  to  Page  48. 


From  Page  46 


(1)  Close,  but  no  cigar.  There  are  numerous  methods  to  use  in  conducting  a 
task  analysis,  but  the  lack  of  a  standard  definition  of  task  analysis  isn't 
the  most  serious  problem.  First,  you  have  to  know  what  a  task  is  in  order 
to  analyze  it.  Try  again  on  Page  46. 


6 


HUMAN  FACTORS  ENGINEERING 


is 


Uj',' 


LESSON  22:  SYSTEMS  ANALYSIS,  OR  THE  BIG  PICTURE 


Welcome  to  the  wide  world  of  systems  analysis.  This  lesson  is  a  foi 
dation  for  much  of  the  Information  which  follows,  so  settle  into  your  ch. 
and  prepar*^  to  l^arn  about  the  'big  picture'  called  'systems  analysis.' 
this  lesson \we' 11  Tfefine  exactly  what  we  mean -by- systems  analyst  s'Vhnd 


^2  why  a  knowledge  of  it  is  so  important  to-yrm_S5b-a  human  factors  spe- 


used  when  conducting  a  systems  analysis.  In  addition,  some  of  the  road 
blocks -y®?xair®texpect«4tofc|®encounteniwill  be  presented  along  with  ways  to 
avoid  them ^  But  before  we  get  all  'wrapped  up'  in  discussions  of  this  sort, 
let's  check\in  on  I.  M.  Eager  and  see  how  'eager'  he  is  to  apply  the  know¬ 
ledge  of  a  human  factors  specialist. 


I.  M.  Eager,  having  discovered  the  hard  way  that  there  are  many 
factors  which  must  be  considered  when  designing  equipment  and  machinery  for 
humans,  had  decided  to  turn  over  a  new  leaf.  He  wished  to  break  from  his 
' trial-and-error '  procedure,  and  concentrate  on  a  completely  systematic 
evaluation  of  the  system  he  was  designing.  Professor  Ed  U.  Kator  had  de¬ 
cided  that  the  best  way  to  introduce  Human  Factors  Engineering  to  Eager  and 
his  fellow  students  was  to  present  a  detailed  overview  of  systems  analysis 
theory  and^prartice. 

C_T^rhe  purposes  of  systems  analysis  can  be  neatly  packaged  into  five 
general  areas: 

— -^l )  Scheduling 

<P2)  Identifying  limiting  factors 

v3)  Establishing  system  performance  criteria 

s<4)  Identifying  and  explaining  various  design  options 

$ 5 )  Evaluating  systems. 

The  following  paragraph^  will  explain  these  purposes  and  present  some 
examples .  v\ 

\ 

When  developing  a  complex  s^tem  such  as  a  large  cargo  jet,  systems 
analysis  is  necessary  if  we  are  to  identify  properly  all  requirements,  and 
if  we  hope  to  understand  the  logicai's^nd  sequential  order  in  which  they 
must  be  accomplished.  For  example,  befobe  we  decide  on  engine  size,  we  need 
to  know  how  heavy  the  aircraft  will  be.  A  proper  systems  analysis  will  help 
us  schedule  various  phases  of  development. 


(Go  on  to  the  next  page) 


From  Page  7 
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Another  purpose  of  systems  analysis  is  the  determination  of  factors 
that  potentially  limit  or  constrain  system  performance.  Such  factors  as 
personnel  skills  and  abilities,  environmental  limitations,  and  cost  esti¬ 
mates  all  must  be  dealt  with  in  evaluating  system  effectiveness.  To  return 
to  our  example,  if  certain  noise  restrictions  exist  for  our  aircraft,  the 
analysis  should  uncover  this  and  enable  us  to  input  this  Information  to  our 
designers. 

The  third  purpose  of  systems  analysis  is  the  establishment  of  perform¬ 
ance  criteria  which  must  be  met  by  the  Interrelated  elements  of  the  overall 
system.  These  criteria  become  standards  for  both  design  and  test  and  eval¬ 
uation.  Our  aircraft,  for  example,  might  have  criteria  such  as:  carry  so 
many  tons  of  equipment;  so  many  people;  travel  at  supersonic  speeds;  and 
have  a  crew  of  eight  men. 

Further  systems  analysis  uses  these  performance  criteria  in  identifi¬ 
cation  and  comparison  of  design  options.  Through  comparison  of  expected 
performance  with  performance  criteria,  the  human  factors  specialist  is  able 
to  use  more  effectively  men  and  machines.  In  our  example  we  might  analyze 
the  option  of  having  only  four  operators  and  some  automated  equipment  to 
accomplish  the  functions  originally  assigned  the  other  four. 

Finally,  performance  measures  of  the  system  and  its  subsystems  are 
needed  to  determine  how  a  'system'  can  be  expected  to  perform  under  actual 
operating  conditions,  or  if  one  'system'  is  better,  or  more  efficient. 

Thus,  you  can  see  that  there  are  a  number  of  ways  in  which  systems 
analysis  can  be  used.  When  do  you  think  systems  analysis  is  most  Important? 

(1)  When  developing  new  systems.  Turn  to  Page  15. 

(2)  When  modifying  traditional  systems.  Turn  to  Page  57. 

(3)  When  a  prototype  is  ready  for  testing.  Turn  to  Page  10. 

(4)  All  of  these  listed  answers.  Turn  to  Page  2. 
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From  Page  75 


(2)  Very  good.  Of  these  choices,  this  was  the  only  task  element.  Engaging 
the  gas  pedal  is  a  subtask  and  driving  the  truck  is  a  function.  Keep  up  the 
good  work. 

Now  that  you  know  the  definitions  and  have  a  feel  for  the  mission  and 
task  of  a  system,  let's  go  back  to  the  parts  of  the  task  analysis  defini¬ 
tion  which  we  haven't  addressed.  Do  you  remember  that  task  analysis  is  a 
process  applied  to  a  task  inventory  and  supporting  data?  Sure  you  do!  Per¬ 
haps  you  also  know  what  a  task  inventory  is.  Do  you? 

(1)  Sure,  it's  a  set  of  all  activities  done  for  a  particular  purpose.  Turn 
to  Page  4. 

(2)  Sure,  it's  a  method  for  classifying  the  levels  of  activities  in  a  sys¬ 
tem.  Turn  to  Page  12. 

(3)  Sure,  it's  a  listing  of  all  tasks  performed  within  one  job.  Turn  to 
Page  64. 

(4)  No,  but  I'm  sure  you're  going  to  teach  me.  Turn  to  Page  23. 


From  Page  26 


(3)  You're  jumping  the  gun.  This  answer  is  part  of  the  next  step  (task 
analysis)  and  function  analysis  assists  you.  However,  first  we  need  to  look 
at  the  results  of  the  functional  analysis  as  it  impacts  the  overall  system 
acquisition  procedure.  Return  to  Page  26. 
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From  Page  5 


(1)  You're  only  thinking  of  the  small  picture.  This  Is  only  one  example  of 
a  factor  which  can  Influence  performance.  Think  big!!  Return  to  Page  5. 


From  Page  15 


(2)  This  answer  Is  Incorrect.  While  presentation  of  alternatives  and  trade¬ 
off  results  to  the  user  is  a  step  in  the  analysis,  It  rarely  fits  as  a 
first  step  in  the  process.  Return  to  Page  15. 


From  Page  66 


(1)  Well,  this  may  be  true,  but  in  this  question  you  (or  another  analyst) 
weren't  performing  the  job.  Your  concern  was  in  asking  workers  about  their 
jobs.  Return  to  Page  66. 


From  Page  8 


(3)  If  you  wait  until  a  prototype  has  been  developed  to  conduct  a  systems 
analysis,  you're  probably  in  a  lot  of  trouble.  Return  to  Page  8. 
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From  Page  69 


(2)  This  is  exactly  right.  You've  learned  very  well. 

Figure  24.2  also  provides  you  with  similar  informst*  jti  in  a  different 
format.  On  this  worksheet,  the  task  element  is  broken  into  its  Human 
Factors  of  perception  (P),  judgement  (J),  and  motor  components  (M).  These 
factors  are  then  judged  as  to  the  level  of  each  that  is  involved  in  per¬ 
forming  every  task  element.  For  example,  the  first  element  (unscrew  three 
hold-down  screws)  is  judged  to  have  a  low  perceptual  component,  but  to  re¬ 
quire  a  moderate  amount  of  judgment  and  motor  abilities.  Now,  why  do  you 
think  judgment  is  required  in  this  simple  subtask? 

(1)  It  is  necessary  to  judge  which  hold-down  screws  to  unscrew.  There  are 
probably  many.  Turn  to  Page  49. 

(2)  It  is  necessary  to  judge  the  tightness  of  the  hold-down  screws.  Turn 
to  Page  59. 

(3)  Judgment  really  isn't  necessary;  the  analyst  just  didn't  want  to  leave 
a  blank  space.  Turn  to  Page  19. 


From  Page  62 


(3)  In  the  later  stages  of  the  acquisition  process  this  will  be  done.  How¬ 
ever,  initially,  we  wouldn't  want  to  reduce  the  design  options  by  Imposing 
function  allocations.  Return  to  Page  62. 


From  Page  31 


(2)  Critical  tasks  are  found  in  the  task  Inventory,  but  this  does  not  tell 
you  how  far  to  break  those  tasks  down.  Think  about  the  particular  purpose 
of  any  particular  task  analysis.  Return  to  Page  31. 
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From  Page  41 


(1)  This  Is  the  same  phase  as  one  other  answer.  Now,  in  this  course,  have 
you  found  two  answers  to  be  equally  correct?  Try  again  on  Page  41. 


From  Page  86 


(4)  These  are  two  measures  used  in  test  and  evaluation  to  assess  whether  or 
not  the  human  has  performed  according  to  the  criteria  set.  Essentially, 
these  measures  can  confirm  whether  your  HFE  involvement  in  systems  analysis 
has  been  successful.  You've  identified  the  end  points.  To  answer  this  ques¬ 
tion  correctly,  you  need  to  focus  on  the  front-end  approach.  Return  to 
Page  86. 


From  Page  9 


(2)  Close,  but  no  cigar.  This  answer  applies  to  a  task  taxonomy.  It  is  used 
for  classifying  activities  into  categories  and  subcategorles .  Therefore,  it 
tells  you  how  to  organize  your  task  Inventory,  but  it  is  not  the  inventory 
itself.  Try  again  on  Page  9. 


From  Page  84 


(1)  If  this  were  true,  then  task  analysis  would  be  a  static,  set  in  con¬ 
crete  event.  Return  to  Page  84. 
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From  Page  86 


(2)  The  current  HFE  emphasis  in  systems  analysis  is  the  identif ication  of 
the  human  performance  specification.  You  were  exactly  right. 

Currently,  the  government  must  explain  in  detail  what  a  system  must  do 
and  how  well  the  system  must  do  it  (whatever  it  is).  That  is,  we  must  now 
talk  about  the  mission  of  the  system  and  what  the  human  performance  must  be 
in  order  to  accomplish  it. 

Now,  that  doesn't  should  too  hard,  does  it?  Well,  this  may  be  more 
difficult  than  you  initially  thought.  The  documents  typically  used  by  HFE 
specialists  have  been  stated  in  equipment  terms.  MIL-STD-1472  and  MIL-HDBK 
759  are  valuable  guides  to  equipment  design,  but  they  really  don't  give  you 
performance  data .  Do  they?  ...  No . 

As  we  said,  the  first  step  in  developing  human  performance  specifica¬ 
tions  is  to  identify  the  purpose  of  mission  of  the  system.  I.  M.  Eager 
really  never  established  the  purpose  of  his  super  helicopter,  he  just 
wanted  it  to  be  super. 

The  purpose  of  a  system  almost  automatically  gives  you  the  criteria 
against  which  to  judge  the  system.  If  Eager's  chopper  is  to  be  able  to  go 
from  earth  to  the  moon  and  back,  then  'fly  from  earth  to  the  moon’  is  its 
mission.  Originally,  ol*  Eager  didn't  have  a  proper  mission  statement. 
Having  a  chopper  which  is  'super'  isn’t  a  statement  of  mission.  Having 
Interstellar  capabilities  isn't  a  mission  statement  either.  To  be  proper, 
however,  the  purpose  of  a  system  (the  mission)  must  be  judged  against  two 
criteria:  usability  and  completeness. 

Usability  can  be  determined  by  asking: 

(1)  Is  this  mission  one  ultimate,  final  purpose  of  this  system?  For 
example,  if  the  ultimate  purpose  of  Eager's  chopper  was  to  fly  to  the  moon, 
then  stating  one  mission  of  the  chopper  as  supersonic  speed  flight  is  an 
ultimate  purpose  in  itself.  There  was,  of  course,  more  intended  for  the 
chopper  than  just  supersonic  speed. 

(2)  Is  this  mission  performed  by  one  defined  system,  or  must  it  be 
performed  by  several  systems?  For  example,  if  Eager  had  stated  that  his 
chopper  had  the  mission  of  maintaining  outer  space  defenses,  he  would  not 
be  correct  in  his  statement.  It  requires  more  than  one  helicopter  or  one 

(  type  of  helicopter  to  defend  outer  space.  So  far,  however.  Eager  has  been 

correct,  'fly  to  the  moon'  is  the  overall  mission  and  supersonic  speed  at- 
<  tainment  a  mission  in  Itself,  which  can  be  performed  by  that  system  (heli- 

f  copter) . 

(  (Go  on  to  the  next  page) 
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From  Page  13 


(3)  Can  we  directly  measure  the  performance  of  the  mission?  In  this 
case,  surely  we  can. 

These  three  questions  must  all  be  given  a  'yes’  answer  if  your  mission 
statement  is  to  be  considered  usable.  The  final  criterion  for  a  system's 
mission  statement  is  its  completeness.  All  the  unitary  missions  which  must 
be  performed  should  be  included  in  the  formal  mission  statement  for  the 
system.  For  example,  Eager's  'fly  to  the  moon'  mission  really  consists  of 
several  unitary  missions,  such  as: 

(1)  Supersonic  speed 

(2)  Orbit  earth 

(3)  Re-enter  earth's  gravity,  and  so  on. 

So  far  we  have  only  addressed  the  mission  statement.  What  is  the  next 
step  in  your  systems  analysis? 

(1)  Break  down  the  mission  into  its  activities  or  functions.  Turn  to  Page 
26. 

(2)  State  the  mission  in  the  mission  element  needs  statement  (MENS).  Turn 
to  Page  19. 

(3)  Determine  if  the  mission  is  needed.  Turn  to  Page  39. 

(4)  All  of  these  are  part  of  the  next  step.  Turn  to  Page  66. 


From  Page  90 


(1)  While  functions  are  assigned  during  this  phase  of  system  development, 
task  analysis  should  be  applied  earlier  to  help  determine  those  functions. 
Return  to  Page  90. 
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From  Page  8 
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(1)  Well  done.  This  was  a  tough  one.  When  working  with  new  systems  there 
I  are  so  many  unanswered  questions.  Unless  a  good  systems  analysis  Is  con- 

i  ducted,  the  probability  of  developing  a  good  system  Is  quite  low. 

What  we've  done  thus  far  Is  give  you  a  general  Impression  of  the  func¬ 
tions  systems  analysis  serves  for  human  factors  specialists.  The  human 
factors  specialist  can  employ  systems  analysis  when  a  need  arises  for 
scheduling,  Identifying  limiting  factors,  establishing  system  performance 
criteria,  Identifying  and  comparing  design  options,  as  well  as  overall  sys¬ 
tem  evaluation.  In  addition,  systems  analysis  can  be  used  In  the  Identifi¬ 
cation  and  evaluation  of  human  performance  reliability.  This,  In  turn,  per¬ 
mits  the  postulation  of  training  and  personnel  skills  requirements. 

Besides  knowing  when  to  use  systems  analysis,  It  Is  also  helpful  to  be 
familiar  with  the  sequential  steps  required.  While  not  always  done  In  a 
rigid  sequence,  all  steps  are  required  In  one  form  or  another.  Some  parts 
of  the  total  system  may  have  already  been  designed  and  tested,  while  time 
constraints  may  eliminate  or  change  the  sequential  order  In  other  In¬ 
stances.  Regardless,  they  combine  to  form  a  model  which  Is  helpful  In 
understanding  the  relationship  between  Human  Factors  Engineering  and  the 
total  system  engineering  process.  Figure  22.1  In  your  supplement  graphical¬ 
ly  displays  this  model.  As  we  continue  through  this  lesson,  as  well  as  some 
«  following  lessons  (e.g.,  task  analysis,  training).  It  will  be  clearer  to 

'  you  how  these  many  steps  fit  together  If  you  constantly  refer  to  this  dla- 

j  gram. 

f  Take  a  look  at  the  diagram.  Considering  what  you've  learned  thus  far 

In  this  course,  and  thinking  about  the  process  of  systems  analysis  In  gen- 
*  eral,  what  would  you  consider  the  first  step  In  systems  analysis? 

r 

(1)  Task  analysis.  Turn  to  Page  98. 

(2)  Presentation  of  alternatives  and  trade-off  results  to  the  user.  Turn 
to  Page  10. 

(3)  Recognition  that  a  problem  exists  and  that  the  solution  may  be  ap¬ 
proachable  from  a  systems  analysis  perspective.  Turn  to  Page  48. 

,  (4)  Selection  and  development  of  'optimum'  system  concept.  Turn  to  Page 

f  100. 

( 
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From  Page  52 


(4)  Not  only  are  all  the  answers  given  true,  but  they  will  all  ultimately 
■lnimize  time  and/or  life-cycle  cost. 

When  the  evolutionary  design  process  which  may  be  capped  by  use  of 
mock-ups  is  completed  and  the  prototype  is  fabricated,  it  is  the  Job  of  the 
human  engineer  to  monitor  the  process.  Often  it  is  the  case  that  what  was  a 
superb  design  on  paper  or  plyboard  requires  modification  to  accommodate 
production  procedures  or  limitations*  A  primary  objective  that  the  human 
engineer  must  keep  in  mind  during  this  process  is  that  factors  desirable 
from  the  HFE  standpoint  are  not  to  be  needlessly  compromised  in  order  to 
facilitate  production  objectives. 

With  each  stage  in  the  acquisition  cycle,  the  system  becomes  progres¬ 
sively  firmer  and  more  concrete.  The  test  and  evaluation  procesa  is  part  of 
every  phase  in  the  system  acquisition  process.  Conducting  test  and  evalua¬ 
tion  at  each  phase  allows  for  change  possibilities  while  the  system  is 
still  flexible  enough  to  accept  and  accommodate  those  changes. 

Results  of  the  test  and  evaluation  analysis,  which  is  conducted  during 
the  production  and  deployment  phase  of  systems  acquisition,  are  expected  to 
Include ; 

(1)  Confirmation  of  human  factors  research  required  to  support  train¬ 
ing  requirements  and  the  operational  concept. 

(2)  Validation  of  LOA  and  TDC  HFE  guidelines,  standards,  processes, 
and  like  needed  documentation.  The  validation  insures  that  the  system  ob¬ 
jectives  can  be  achieved  by  the  personnel  generally  available  to  the  user 
organization  and  those  who  have  been  given  only  the  training  planned. 

(3)  Final  evaluation  of  training  aids  and  devices  and  special  training 
requirements . 

What  can  we  conclude  is  the  practical  thrust  of  the  HFE  effort  during 
test  and  evaluation? 

(1)  Defining  the  selection  criteria  for  determining  who  will  be  expected  to 
operate  the  system.  Turn  to  Page  100. 

(2)  To  determine  the  human  performance  levels  or  standards.  Turn  to  Page 
5. 

(3)  Reaching  a  decision  whether  or  not  a  man  can  operate  or  maintain  the 
system  in  order  to  meet  the  objectives  of  its  existence.  Turn  to  Page  65. 

(4)  Subsequent  to  test  and  evaluation,  HFE  analyses  seek  to  define  what  is 
required  in  order  to  qualify  prospective  operators  and  malntainers  to  meet 
system  objectives.  Turn  to  Page  46. 
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From  Page  61 


(2)  Sorry,  but  the  question  asked  when  anthropometry  should  be  Introduced, 
indicating  a  first  consideration.  This  type  of  HFE  data  is  important  during 
the  concept  exploration  phase,  but  it  should  be  a  consideration  even 
earlier.  When?  Return  to  Page  61. 


From  Page  85 


(4)  This  answer  is  an  example  of  an  overall  mission  statement  which  should 
be  broken  down  into  a  series  of  unitary  mission  statements  ...  A  list  of 
required  functions  per  mission  statement  ...  A  list  of  tasks  per  function. 
If  you  are  confused  about  the  differences  among  these  concepts,  you'd  bet¬ 
ter  reread  the  last  few  pages  before  answering  this  question  again.  Good 
luck.  Return  to  Page  85. 


From  Page  90 


(3)  Waiting  until  a  prototype  exists  is  too  late.  Task  analysis  should  be 
done  sooner.  Return  to  Page  90. 


From  Page  59 


(3)  This  is  Indeed  a  valid  statement,  but  there  is  some  important  prelimi¬ 
nary  activity  to  be  completed  before  identifying  alternatives.  Return  to 
Page  59. 
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From  Page  29 


I - 1 

(4)  Very  good.  A  task  is  a  combination  of  related  activities  which  are  done 
to  achieve  a  particular  purpose. 

As  you  now  know,  a  task  is  a  set  of  activities  done  for  a  particular 
purpose.  These  activities  are  composed  of  perceptions,  judgments,  skills, 
and  knowledge  that  go  into  making  a  response.  A  'subtask, '  therefore,  is  a 
set  of  activities  which  fulfill  a  portion  of  the  task.  Finally,  a  'task 
element'  is  the  smallest  definable  unit  of  behavior  required  in  completing 
a  task  or  subtask. 

In  order  to  give  you  some  practice  in  thinking  about  the  various 
factors  involved  in  task  analysis,  let's  take  an  example.  In  our  example, 
the  man-machine  system  is  a  truck  and  driver.  The  mission  of  the  system  is 
to  deliver  a  message  to  command  headquarters  from  point  X.  A  function  of 
the  system  would  be: 

(1)  To  drive  the  truck  from  point  X  to  command  headquarters.  Turn  to  Page 
75. 

(2)  To  deliver  the  message.  Turn  to  Page  81. 

<3)  To  start  the  engine  of  the  truck.  Turn  to  Page  3. 

(4)  To  change  a  flat  tire.  Turn  to  Page  63. 


From  Page  61 


(3)  Sorry,  but  the  question  asked  when  anthropometry  should  be  introduced. 
Indicating  a  first  consideration.  This  type  of  HFG  data  is  important  during 
the  concept  exploration  phase,  but  it  should  be  a  consideration  even 
earlier.  When?  Return  to  Page  61. 
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From  Page  70 


(3)  No.  While  DOD  Directive  5000.1  lays  out  the  requirements  for  HFE ,  the 
individual  service  which  undertakes  the  procurement  is  primarily  respon¬ 
sible  for  the  details  of  HFE  application.  Return  to  Page  70. 


From  Page  14 


(2)  Well,  we  could  have  made  this  the  correct  answer,  but  aren't  writing 
the  MENS  and  identifying  the  mission  just  two  sides  of  the  same  coin?  We 
really  are  looking  for  the  next  conceptual  step.  Oh,  if  you  insist,  we  will 
pat  your  back  for  being  technically  correct.  However,  just  to  be  a  nice 
person,  why  don't  you  try  another  answer  so  that  the  lesson  can  continue? 
Thanks.  Return  to  Page  14. 


From  Page  11 


(3)  Aw,  you  really  don't  think  this  was  the  correct  answer,  did  you?  Pick 
another  answer  on  Page  11. 
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From  Page  62 


(1)  Well,  In  this  case  you're  incorrect.  This  functional  allocation  process 
is  one  of  several  which  contributes  to  the  essence  of  HFE,  but  we  don't 
want  to  apply  it  yet.  Return  to  Page  62. 


From  Page  76 


(4)  Oops  —  One  of  these  truly  is  correct.  Remember,  you  need  conditions, 
action  object,  and  performance  standards.  Return  to  Page  76. 


From  Page  74 


(4)  Relative  weighting  is  a  measure  that  is  flexible  to  adjustment  within 
the  framework  of  a  model.  It  is  an  Important  detail  feature,  not  a  requi¬ 
site  to  design  of  the  measurement  model.  Return  to  Page  74. 


From  Page  97 


(2)  While  it  is  Important  that  the  measurement  criteria  used  in  any  one 
round  of  trade-offs  remain  constant,  the  needs  to  be  met  and  the  questions 
to  be  answered  will  change  as  the  system(s)  become  better  defined.  Obvious¬ 
ly,  this  is  not  the  answer.  Return  to  Page  97. 
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From  Page  61 


(4)  We  hate  to  say  this  Is  the  wrong  answer,  but  it  is.  It  is  wrong  only 
because  the  question  asked  for  the  first  consideration  of  such  HFE  data.  It 
is  true  that  such  HFE  information  should  be  considered  in  all  phases,  but 
when  do  you  initially  introduce  it?  Return  to  Page  61. 


From  Page  79 


(1)  There  is  some  truth  to  this  approach;  however,  not  only  is  there  the 
technical  risk  of  associated  systems  deficiencies  being  keyed  to  HFE  defi¬ 
ciencies,  experience  indicates  that  unless  HFE  issues  are  addressed  early 
in  the  development  process,  they  may  never  be  resolved.  Return  to  Page  79. 


From  Page  86 


(1)  This  answer  is  an  equipment-oriented  HFE  interest.  We  want  to  ensure 
this  compatibility,  but  we  want  to  state  this  In  terms  of  its  effect  upon 
the  human.  Ask  yourself  questions  such  as,  'what  must  the  operator  do?  What 
are  the  goals  to  be  reached?  How  does  the  human  function  to  reach  these 
goals? '.. .Now  try  again.  Return  to  Page  86. 


From  Page  59 
l 

f  (1)  You  are  certainly  right  that  dollar  value  is  most  often  a  key  decision 

factor;  however,  other  things  need  to  be  done  before  the  way  the  decision 
(  is  to  be  made  is  determined.  Return  to  Page  59. 
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From  Page  4 


(3)  You're  right.  Time  and  accuracy  are  the  two  characteristics  which  are 
basic  to  human  performance.  The  other  answers  of  number  of  type  of  error, 
user  acceptability,  and  probability  of  success  are  all  examples  of  addi¬ 
tional  forms  for  describing  either  performance  standards  or  acceptance. 

Time  of  performance  is  usually  described  in  two  ways:  reaction  time 
and  actual  performance  time.  Reaction  time  is  a  measure  of  how  long  it 
takes  an  individual  to  respond  once  a  stimulus  has  been  presented.  For  ex¬ 
ample,  how  long  does  it  take  to  hit  the  shutdown  control  once  the  emergency 
display  is  activated?  Performance  time  is  typically  used  on  task  descrip¬ 
tions.  For  example,  the  operator  will  adjust  dials  1,  2,  and  3  to  within  a 
10-degree  error  range  in  1.5  minutes.  The  1.5  minutes  is  the  maximum  ac¬ 
ceptable  performance  time. 

Errors  may  be  specified  in  several  ways.  You  can  specify  the  total 
number  of  errors ,  the  type  of  errors  made ,  the  number  of  errors  per  type . 

We  have  been  discussing  performance  characteristics  and  which  of  these 
attributes  we  measure.  In  systems  analysis  we  need  to  develop  performance 
standards  for  each  task.  That  is,  we  want  to  develop  the  criteria  for  per¬ 
formance  success.  These  standards  or  specifications  are  of  two  basic  forms: 
probability  of  task  success  or  time  and  error.  The  probability  of  success 
format  combines  both  time  and  error  (number  and  type)  and  is  the  form 
recommended  in  recent  military  publications. 

Well,  we  have  come  full  circle.  The  probability  of  success  statement 
should  be  included  in  the  mission  statement.  By  attending  to  human  perform¬ 
ance  specifications  early  in  the  system  acquisition  cycle,  we  human  factors 
specialists  will  be  able  to  assure  that  the  human  is  capable  of  operating 
or  maintaining  the  equipment  of  the  acquired  system.  After  all,  that  is  one 
of  the  major  principles  of  a  human  factors  specialist. 

This  lesson  has  been  detailed  and  you  could  probably  do  with  a  recap 
before  ending.  We  have  suggested  that  the  systems  analysis  process  be 
focused  on  human  performance  specifications.  In  order  to  develop  these 
specifications  several  procedural  steps  were  presented: 

(1)  Develop  purpose(s)  of  system. 

(2)  Define  system  functions  for  each  mission. 

(3)  Decompose  system  functions  to  tasks. 

(4)  Determine  task  conditions. 

(5)  Develop  performance  standards. 

(Go  on  to  the  next  page) 
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From  Page  22 
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We  recommend  that  you  read  two  Human  Engineering  Lab  (HEL)  technical 
memoranda  for  a  more  complete  understanding  of  these  concepts.  First,  TM 
7-80  by  Kaplan  and  Crooks  is  a  report  dealing  with  the  development  of  per¬ 
formance  standards.  Most  of  this  lesson  was  developed  using  this  memoran¬ 
dum.  Second,  TM  29-76  by  Berson  and  Crooks  is  a  must  for  understanding  how 
to  analyze  human  performance  data.  You  will  be  using  this  document  in  sub¬ 
sequent  lessons  in  this  course,  so  you  may  as  well  be  prepared  by  reading 
ahead . 


So,  we  come  to  the  close  of  Lesson  22.  Take  a  break.  Reward  yourself 
with  an  ice  cream  cone  and  get  ready  for  your  next  two  lessons  which  deal 
with  task  analysis.  This  topic  is  so  important  that  two  lessons  (23  and  24) 
will  be  given  to  you.  We  will  keep  our  memory  banks  and  storage  places  warm 
and  ready  to  greet  you  then.  See  you  in  Lesson  23. 


From  Page  9 


(4)  Right  you  are.  This  may,  in  fact,  be  true  and  you  don't  know  what  a 
task  inventory  is.  However,  if  you  look  at  the  other  answers,  you  will  see 
one  which  is  correct  and  defines  the  words  'task'  and  'inventory.' 


From  Page  50 


(1)  Correct.  From  this  example  it  is  possile  to  make  decisions  involving 
design  reconsiderations,  training  requirements,  and  so  on.  It  is  a  very 
thorough  and  well-summarized  form. 

With  this  piece  of  information  we  come  to  the  end  of  the  task  analysis 
trail.  In  this  lesson  you  learned  about  the  task  analysis  process,  which 
Involved  identifying  tasks,  subtasks,  and  task  elements;  developing  SBOS; 
and  identifying  supporting  skills  and  knowledge.  In  addition,  you  saw 
various  types  of  task  analysis  worksheets  ranging  from  really  simplistic 
ones  to  LSAR.  Task  analysis  is  a  difficult  topic  to  understand,  but  since 
you  will  be  constantly  exposed  to  it  in  your  Job  as  a  human  factors  spe¬ 
cialist,  we  have  given  you  two  lessons  on  it.  You  next  lesson  will  deal 
with  trade-off  analysis.  Be  sure  to  bring  both  your  supplement  and  your  wit 
t  with  you  when  you  return  to  the  terminal  of  knowledge.  In  fact,  it  would  be 

a  good  idea  to  look  over  the  diagrams  in  your  supplement  before  you  return 
f  to  the  next  lesson.  See  you! 
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(3)  Right  again.  These  four  elements  combined  can  provide  a  baseline  alter¬ 
native. 

The  second  step  of  a  trade-off  deals  with  identifying  the  potential 
for  development  of  alternative  equipment  designs  based  on  manpower  require¬ 
ment  trade-offs.  Remember  that  these  manpower  requirements  are  themselves 
based  on  human  performance  requirements.  The  alternatives  might  be  speci¬ 
fied  with  respect  to  any  number  of  selected  criteria,  depending  on  what 
potential  trade-offs  are  available.  Alternatives  may  be  specified,  alterna¬ 
tive  subsystems  might  be  identified,  or  maintenance  concepts  or  technology 
might  be  evaluated.  Each  weapon  system  analysis  can  be  expected  to  Involve 
a  different  set  of  alternatives.  It  is  noteworthy  that  overall  safety  and 
health  considerations  are  a  key  consideration  in  developing  alternatives. 

During  the  third  procedural  step,  each  alternative  would  be  subjected 
to  analysis  of  resource  requirements.  This  analysis  would  include  manpower 
and  training  requirements,  the  procedures  for  measurement  of  training  ef¬ 
fectiveness,  as  well  as  estimates  of  life-cycle  costs.  Additionally,  each  I 

alternative  is  analyzed  in  terms  of  its  strengths  and  weaknesses  in  satis-  | 

fying  the  overall  performance  requirements. 

Typically,  a  tabular  matrix  is  developed  to  summarize  the  chief  char¬ 
acteristics.  Understandably  for  complex  weapon  systems,  the  analysis  of 
each  alternative  will  represent  an  effort  of  some  significant  magnitude 
that  would  fully  justify  the  use  of  any  automated  means  attainable  and 
would  fully  exercise  mathematical  decision  theory. 

In  any  event,  however,  a  standardized  analysis  must  be  conducted  for 
each  alternative. 

Which  of  the  choices  given  below  best  summarizes  the  major  analysis  of 
the  first  three  trade-off  steps? 

(1)  Maximize  life-cycle  potential  and  minimize  resource  requirements.  Turn 
to  Page  5. 

(2)  Maximum  system  performance  capability  for  minimum  cost  with  minimum 
manpower  and  minimum  training.  Turn  to  Page  97. 

(3)  Maximize  capability  and  minimize  manpower  and  training  allocations. 

Turn  to  Page  98. 
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From  Page  66 


(2)  Very  good.  Often,  when  people  are  dissatisfied  with  their  situation, 
they  are  unable  or  unwilling  to  reveal  the  true  source  of  their  dissatis¬ 
faction.  At  these  times,  the  complaints  about  system  effectiveness  would  be 
symptoms  of  an  underlying  problem. 

In  the  process  of  breaking  down  the  tasks  into  subtasks  and  task  ele¬ 
ments,  you  will  be  writing  statements  which  describe  those  tasks,  subtasks, 
or  task  elements.  Those  statements  are  called  'task  statements,'  even 
though  they  man  refer  to  subtasks  or  task  elements  as  well  as  to  tasks.  The 
task  statements  always  contain  a  verb  (action  to  be  performed)  along  with 
relevant  Items  of  knowledge  and  objects  involved  in  the  action;  for  ex¬ 
ample,  a  simple  statement  such  as  'read  book  X.'  read  is  an  action  verb  and 

book  Is  the  object.  The  result  of  your  work,  then,  Is  a  set  of  task  state¬ 

ments.  Any  task  statement  with  a  verb  gets  you  three  demerits. 

So  far,  we  have  focused  on  stage  one  of  the  task  analysis.  Now  tell 
me,  what  Is  the  purpose  of  stage  one? 

(1)  To  determine  the  appropriate  sequence  of  tasks,  subtasks,  and  task  ele¬ 
ments  for  performing  a  job.  Turn  to  Page  63. 

(2)  To  determine  every  element  of  every  task  in  a  job.  Turn  to  Page  81. 

(3)  To  develop  a  list  ok  every  single  task  which  makes  us  a  job.  Turn  to 

Page  45. 

(4)  To  identify  a  job's  critical  tasks,  subtasks,  or  task  elements.  Turn 
to  Page  35. 


From  Page  89 


(3)  You  missed  a  beat.  While  we  look  for  the  best  outcomes  to  meet  defined 
minimum  requirements,  we  look  to  meet  their  needs  with  the  least  assets 
expended.  Return  to  Page  89. 
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From  Page  14 


(1)  Right  on.  Once  the  mission  of  the  system  has  been  stated,  then  you  need 
to  break  that  down  into  the  activities  which  will  accomplish  that  mission. 

After  the  mission  statement  has  been  defined,  the  HFE  specialist  next 
must  break  down  the  mission  into  activities  and  functions.  The  purpose  of 
function  analysis  is  to  determine  how  each  required  function  can  be  per¬ 
formed  in  the  system  and  to  consider  the  various  alternatives  that  might 
lead  to  successful  completion  of  the  mission.  Regardless  of  the  specific 
steps  in  analyzing  system  functions,  the  processes  normally  Involved  remain 
unchanged.  First  you  examine  each  system  function  to  determine  the  kinds  of 
capabilities  needed  to  meet  the  system  performance  requirements.  In  addi¬ 
tion,  you  will  explore  possible  combinations  of  man-equipment  capabilities 
in  terms  of  the  trade-offs  involved. 

As  a  final  result,  the  functions  analysis  process  will  assist  you  in 
doing  which  of  the  following? 

(1)  Determining  mission  objectives.  Turn  to  Page  32. 

(2)  Determining  which  design  approach  will  maximize  overall  system  cost  ef¬ 
fectiveness.  Turn  to  Page  62. 

(3)  Determining  subtasks  and  task  elements  needed  by  the  human  in  order  to 
perform  the  required  tasks.  Turn  to  Page  9. 

(4)  All  of  these  answers  are  correct.  Turn  to  Page  46. 


From  Page  70 


(2)  This  answer  is  only  partially  correct.  Many  unique,  but  low  priced, 
items  are  afforded  a  much  more  thorough  HFE  treatment  than  might  be  given 
to,  say,  an  adaptation  of  a  proven  system  for  military  use.  Return  to  Page 
70. 
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HUMAN  FACTORS  ENGINEERING 

LESSON  23:  TASK  ANALYSIS  I 


As  you  may  recall  (how  could  you  possible  forget!),  I.  M.  Eager  really 
was  eager  to  learn  after  his  rather  strange  dream.  He  was  now  glad  to  be 
going  to  his  new  assignment  because  he  would  learn  the  techniques  and 
methods  necessary  for  designing  his  perfectly  super  chopper.  Remember,  in 
real  life  Eager  was  interested  in  designing  and  constructing  a  perfect 
helicopter  which  had  land,  sea,  and  air  capabilities.  His  dream  had  illus¬ 
trated  for  him  the  areas  with  which  he  needed  to  be  knowledgeable. 

When  he  arrived  at  his  new  command,  lo  and  behold,  he  met  his  teacher, 

CPT  Ed  U.  Kator.  (Strange  isn't  it?)  Anyway,  CPT  Ed's  first  lessons  were 
about  systems  acquisition  and  systems  analysis.  After  these  thought-provok¬ 
ing  sessions,  Eager  was  ready  to  get  his  feet  wet,  so  to  speak.  He  was 
eagerly  anticipating  the  upcoming  sessions  on  task  analysis,  because  these 
sessions  would  not  only  be  informative,  but  would  allow  him  to  do  some  of 
the  things  he  had  been  learning  as  well.  On  the  morning  of  the  first  day  of 
the  task  analysis  seminars,  Eager  awakened  early,  dressed,  and  rushed  to 
class. 

In  this  lesson  YLesson  23Q»-y®j.  will  •  leBHrn  the  history  of  task  analy¬ 
sis,  what  its  aims  are,  what  factors  go  into  a  task  analysis,  and  the  uses 
of  task  analysis.  Figure  23.1  summarizes  the  overall  process.  Because  of 
the  importance  and  complexity  of  the  upcoming  material,  two  lessons  (23  and 
24)  are  devoted  to  this  topic.  Lesson  24  will  provide  you  with  information 
about  the  task  analysis  process  and  the  techniques  and  the  various  work¬ 
sheets  that  can  be  used.  So,  without  further  ado,  let's  begin. 

Task  analysis  has  long  been  considered  one  of  the  most  treacherous 
areas  of  Human  Factors  Engineering.  Perhaps  an  example  will  help  you  to  be  ^ 
aware  of  the  confusion  which  can  exist  when  dealing  with  task  analysis.  y 

In  1966  the  Army  document  called  the  'Authorized  Data  List'  (ADL)  was 
used  as  a  source  of  data  item  descriptions  (DID).  From  this  list  government 
personnel  could  select  the  appropriate  'DID*  to  put  into  government  con¬ 
tracts.  The  Main  Battle  Tank-70  Project  used  an  item  from  the  ADL  to  re¬ 
quest  a  task  analysis  for  this  project.  When  it  was  delivered,  however,  the 
document  was  32  Inches  high!  Nobody  in  the  government  was  able  to  make  much 
use  of  it. 


(Go  on  to  the  next  page) 
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I _ I 

In  addition  to  the  possibility  of  being  confusing  because  of  such 
length,  task  analysis  can  be  done  in  a  variety  of  ways,  using  a  variety  of 
techniques.  This,  in  and  of  itself,  wouldn't  necessarily  cause  confusion. 
However,  until  recently,  there  was  no  uniform  definition  as  to  what  a  task 
was.  Well-intentioned  contractors  could,  and  did,  apply  task  analysis 
methods  to  their  own  idea  of  a  task.  Often  this  idea  wasn't  what  the  con¬ 
tracting  agency  had  in  mind. 

To  date,  this  lack  of  agreement  as  to  what  constitutes  a  task  has  been 
the  single  most  Intractable  problem  with  task  analysis.  In  1978,  the  Test 
and  Evaluation  Subgroup  of  the  DOD  HFE  Technical  Advisory  Group  was  estab- 
listed.  This  subgroup  was  composed  of  civilian  and  military  personnel  from 
the  Army,  Navy,  and  Air  Force. 

In  March  1979,  this  subgroup  developed  a  scheme  for  classifying  and 
organizing  human  behavior  which  was  found  acceptable  by  80  percent  of  the 
human  factors  engineering  community.  Part  of  this  scheme  deals  with  the 
definition  of  a  task.  Currently,  a  new  military  standard  is  being  con¬ 
structed  which  will  contain  the  test  and  evaluation  subgroup's  recommenda¬ 
tions.  We,  having  great  perceptive  powers,  have  access  to  all  the  latest 
Information.  This  lesson  and  the  next  (23  and  24)  will  provide  you  with 
information  about  task  analysis  which  was  developed  by  this  test  and  evalu¬ 
ation  subgroup. 

Okay,  you've  gotten  a  short  recent  history  of  developments  in  the 
field  of  task  analysis  and  you've  been  warned  that  the  ground  is  treacher¬ 
ous.  You  also  know  that  a  good  deal  of  confusion  exists  about  what  a  task 
really  is — even  among  'experts'  in  the  field!  Now  you  probably  want  to  know 
what  task  analysis  is  (demanding,  aren't  you!).  Well,  you've  come  to  the 
right  place  for  the  answer.  Task  analysis  is  an  analytic  process  applied  to 
a  task  inventory  and  supporting  data  to  produce  a  description  of  some  as¬ 
pect  of  the  human  component  in  a  manned  system.  It  further  provides  infor¬ 
mation  for  design,  training,  test  and  evaluation,  manning,  and  workload. 

That's  a  mouthful,  but  remember,  you  asked  the  question.  Perhaps  it 
will  help  to  make  things  clearer  if  we  break  the  definition  down  into  its 
parts. 


(Go  on  to  the  next  page) 
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From  Page  28 


(1)  Task  analysis  Is  a  process — a  series  of  steps  or  procedures. 

(2)  Task  analysis  Is  done  to  generate  Information. 

(3)  This  Information  consists  of  a  set  of  descriptions  about  the  human 
component  of  a  manned  system. 

(4)  The  task  inventory  is  a  set  of  statements  of  the  behaviors  which 
make  up  a  task. 

(5)  Task  analysis  Is  applied  to  a  task  Inventory  and  Its  supporting 

data. 


(6)  The  outcome  of  task  analysis  provides  information  for  five 
specialty  programs:  design,  training,  test  and  evaluation,  manning,  and 
workload. 

You  know  what  the  aim  of  task  analysis  is.  Now,  let's  examine  various 
facets  of  the  job  and  define  them.  First,  what  the  man-machine  system  is 
supposed  to  accomplish  is  the  'mission'  of  the  system.  Second,  the  'func¬ 
tions'  of  the  system  are  the  broad  range  of  activities  performed  by  the 
man-machine  system.  Third,  a  combination  of  all  the  human  performance  re¬ 
quirements  necessary  for  operation  and  maintenance  by  one  individual  is  a 
definition  of  a  'job.'  For  example,  the  job  of  truck  driver  would  include 
such  activities  as  steering  the  vehicle,  stopping  the  truck,  and  changing  a 
tire. 


Now,  we  ha/e  been  narrowing  in  on  our  definitions:  from  mission,  to 
function,  to  job.  Next  comes  a  definition  of  a  task.  Which  of  the  following 
do  you  think  is  a  definition  of  a  task? 


(1)  A  chore  you  had  to  do  at  home  in  order  to  get  your  allowance.  Turn  to 
Page  67. 

(2)  A  goal  of  the  man-machine  system.  Turn  to  Page  33. 

(3)  A  series  of  perceptions  about  the  job.  Turn  to  Page  57. 

(4)  A  composite  of  related  activities  which  are  performed  for  an  immediate 
purpose.  Turn  to  Page  18. 
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From  Page  79 


(2)  Not  at  all.  Time  doesn't  stand  still  for  the  human  factors  engineer  to 
'bless*  a  design.  Not  only  would  this  approach  to  HFE  be  unwleldly,  but  It 
has  been  demonstrated  time  and  again  that  once  a  design  has  been  settled 
on.  It  becomes  doubly  difficult  to  overcome  the  'pride  in  authorship'  of 
Its  originator.  Return  to  Page  79. 


From  Page  46 


(2)  Correct.  The  lack  of  a  standard  definition  of  exactly  what  a  task  Is, 
is  indeed  the  single  moat  Important  problem  In  the  area  of  task  analysis. 
Keep  up  the  good  work. 

As  the  last  question  Indicated,  there  Is,  or  has  been  In  the  past,  no 
standardized  definition  of  a  task.  The  recent  tri-service  group,  however, 
has  proposed  definitions  for  task  analysis  components.  These  definitions 
are  contained  in  your  supplement  as  Table  23.1.  Figure  23.1  In  your  supple¬ 
ment  graphically  portrays  the  topic  of  task  analysis  as  we've  presented  It 
so  far.  Look  at  Figure  23.1.  It  shows  you  a  theoretical  scheme  for  task 
analysis.  On  the  left,  you  see  the  inputs  to  task  analysis,  the  task  Inven¬ 
tory,  and  supporting  data.  In  the  middle  Is  task  analysis.  Notice  that  It 
Is  shown  as  a  process.  On  the  right  are  the  five  purposes  of  task  analysis 
which  we  have  discussed. 

Well,  since  task  analysis  can  be  conducted  at  any  time,  It  must  be 
time  to  learn  about  task  analysis  methods.  In  this  next  section  you  will 
learn  about  the  task  analysis  worksheet  and  the  various  steps  to  use  In 
setting  up  a  study  of  tasks,  subtasks,  and  task  elements. 

What  you  have  to  use  for  the  task  analysis  will  be  a  task  Inventory. 
(Any  supporting  data  that  Is  available  is  also  helpful.)  Critical  tasks 
from  that  inventory  are  selected  and  the  task  analysis  is  applied  to  those 
critical  tasks. 


(Go  on  to  the  next  page) 
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From  Page  30 


There  are  three  stages  involved  in  a  task  analysis  process: 

(1)  Identification  of  tasks,  subtasks,  and  task  elements. 

(2)  Development  of  specific  behavioral  objectives  for  the  tasks. 

(3)  Identification  of  supporting  skills  and  knowledge  for  the  tasks. 

In  stage  one,  you  do  the  actual  breakdown  of  the  tasks  into  subtasks 
and  task  elements.  Remember,  we  are  assuming  the  tasks  have  already  been 
identified  in  the  task  inventory.  Two  questions  are  important  in  this 
state:  (1)  How  far  do  you  continue  the  task  breakdown?  (2)  How  do  you 
actually  accomplish  the  breakdown? 

See  if  you  can  answer  the  first  of  these  questions.  How  far  do  you 
continue  the  task  breakdown? 

(1)  The  breakdown  should  always  continue  to  the  task  element  level  to  in¬ 
sure  completeness.  Turn  to  Page  33. 

(2)  It  depends  upon  the  critical  tasks  found  in  the  task  inventory.  Turn 
to  Page  11. 

(3)  It  depends  upon  the  output  (design,  training,  etc.)  for  which  the  task 
analysis  is  being  conducted.  Turn  to  Page  78. 

(4)  The  breakdown  need  only  be  to  the  task  level,  because  the  inventory 
supplies  this  information.  Turn  to  Page  42. 
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From  Page  69 


(1)  The  subtask  was  listed  in  Column  3.  Sorry.  Try  again  on  Page  69. 
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(3)  Yes,  this  is  true,  but  the  examples  cited  are  not  primary  justification 
for  Its  fabrication.  Return  to  Page  52. 


From  Page  26 


(1)  Oh,  come  on.  You  can't  be  serious.  Mission  objectives  should  be  dealt 
with  long  before  functional  analysis  Is  ever  used.  Return  to  Page  26. 


From  Page  97 


(3)  You're  half  right.  While  tne  outcomes  of  one  analysis  evolve  to  become 
the  baseline  of  the  next,  the  general  procedures  remain  quite  constant. 
Return  to  Page  97  for  another  answer. 


From  Page  4 


(1)  User  acceptability  does  contribute  to  successful  performance.  But  it 
really  isn't  an  attribute  or  characteristic  of  performance  Itself.  The  ac¬ 
curacy  portion  of  this  answer  is  correct,  however.  Try  again.  Return  to 
Page  4. 


From  Page  29 


(2)  No,  the  goal  of  the  man-machine  system  is  the  overall  mission  of  the 
system,  not  the  task.  Return  to  Page  29. 


From  Page  31 


(1)  This  isn't  necessarily  so.  It  may  be  true  in  the  design  phase  of  the 
system,  but  do  you  think  it  is  necessary  in  the  training  phase?  Try  again 
on  Page  31. 


From  Page  54 


(2)  While  this  is  a  good  design  consideration  and  may  encourage  positive 
transfer,  it  is  not  the  best  answer.  Return  to  Page  54. 


From  Page  83 


(4)  Task  analysis  is  performed  to  analyze  human  behaviors,  not  equipment. 
Return  to  Page  83  and  try  again. 


From  Page  96 


(2)  Not  quite.  Decision  theory  mathematics  has  been  demonstrated  to  be  ef¬ 
fective  in  reaching  and  supporting  valid  conclusions.  However,  there  is 
something  more  basic  to  be  done  than  answering  questions  under  conditions 
of  uncertainty.  Return  to  Page  96. 


From  Page  50 


(2)  Well,  not  totally.  Design  purposes  are  well  served  by  this  information, 
but  so  are  other  outcomes.  The  form  provides  such  information  as  the  tools 
and  aids  which  need  to  be  used.  This  information  is  important  in  training 
development.  The  figure  also  gives  error  rates  which  can  be  used  in  design, 
training,  test  and  evaluation,  and  so  on.  The  required  answer  to  this  ques¬ 
tion  is  broader  than  the  answer  you  selected.  Try  again  on  Page  50. 
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From  Page  25 


(4)  Correct.  Congratulations! 

Now,  let's  go  on  to  stage  two.  In  this  stage  the  task  statements  are 
converted  to  specific  behavioral  objectives  (SBOS).  The  SBO  describes  the 
action  of  the  task  (subtask  or  task  element),  the  conditlon(s)  under  which 
the  action  is  to  be  performed,  and  the  standard(s)  or  criterion  of  perform¬ 
ance  for  that  action. 

Here  are  a  number  of  SBO  examples  to  help  you  better  understand  the 
concept : 

(1)  Given  an  electric  typewriter  and  paper  (conditions),  type  (action) 
a  minimum  of  50  words  per  minute  (standard  1)  with  no  more  than  five  errors 
(standard  2). 

(2)  Given  last  year's  expenditures  (condition  1),  this  year's  needs 
(condition  2),  and  projected  income  (condition  3),  prepare  (action)  next 
year's  budget  within  2  days  (standard). 

(3)  Given  a  malfunctioning  car  door  lock  (condition  1),  a  maintenance 
manual  (condition  2),  tools  (condition  3),  and  parts  (condition  4),  repair 
the  lock  In  1  hour  (standard). 

Conditions  are  usually  easy  to  determine  and  recognize.  Wherever  pos¬ 
sible,  standards  should  be  stated  in  quantitative  terms,  as  shown  above. 
Time  and  accuracy  are  the  two  most  widely  used  terms.  The  action  terms  In 
an  SBO  should  be  aimed  at  the  person  who  will  perform  them,  not,  for  ex¬ 
ample,  at  the  trainer,  if  training  is  the  outcome  in  question.  Also,  the 
action  terms  always  require  an  object.  The  object  of  the  examples  above 
were  '50  wpm,'  'budget,'  and  'lock,'  respectively.  The  action  part  of  the 
SBO  tells  you  what  to  do  to  what.  Which  of  the  following  is  an  example  of 
an  incorrect  action  statement? 

(1)  The  trainee  will  be  able  to  name  parts  of  the  lawn  mower.  Turn  to  Page 
76. 

(2)  Turn  on  the  power  of  the  lawn  mower.  Turn  to  Page  69. 

(3)  Identify  the  problem.  Turn  to  Page  99. 

(4)  Direct  the  formation  to  the  designated  area.  Turn  to  Page  91. 
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From  Page  61 


(1)  Very  good.  Developing  the  MENS  occurs  first  In  the  system  acquisition 
process,  and,  therefore,  this  Is  when  such  Information  should  be  Intro¬ 
duced.  Please  be  aware,  however,  that  all  these  phases  require  HFE  Informa¬ 
tion  such  as  anthropometric  data. 

It  Is  during  the  concept  exploration  phase  that  an  experimental  proto¬ 
type  or  breadboard  prototype  may  be  developed.  An  example  of  this  kind  of 
prototype  can  be  found  In  HEL  TM  29-76  on  Page  58.  The  breadboard  type  of 
mock-up  Is  typically  constructed  of  cardboard,  wood,  or  sheet  metal  and  Is 
meant  to  represent  the  finished  product.  One  of  Its  primary  purposes  Is  to 
evaluate  system  design.  Operators  can  go  through  the  actions  and  motions 
they  will  have  to  make  when  the  equipment  Is  In  operational  use.  Changes 
needed  in  design,  personnel,  and  training  can  be  determined  prior  to  ex¬ 
pensive  full-scale  development. 

The  'demonstration  and  validation  phase'  immediately  precedes  the  next 
major  decision  milestone  In  the  system  acquisition  process.  This  phase  en¬ 
compasses  preliminary  design,  during  which  the  engineering  characteristics 
of  the  various  alternative  designs  are  established  and  delineated.  The  pri¬ 
mary  objective  of  the  demonstration  and  validation  phase  Is  to  provide 
justification  for  full-scale  engineering  development  decisions  by  the  Sys¬ 
tems  Acquisition  Review  Council  (SARC).  This  effort  encompasses  such  Issues 
as  logistics  requirements,  preliminary  estimates  of  cost  over  the  life- 
cycle  of  the  system,  and  definition  of  the  technical  risks  and  their  poten¬ 
tial  solutions. 

Subsequent  to  approval  of  full-scale  engineering  development  and  prior 
to  the  next  step,  the  Required  Operational  Capability  (ROC)  statement  is 
promulgated  for  major  Army  systems.  Navy  systems  development  procedure 
labels  a  similar  document  as  'To  Level  Requirements'  (TLR).  The  ROC  states 
concisely  the  minimum  essential  operational  capabilities,  and  technical, 
logistical,  and  cost  information  needed  to  initiate  full-scale  development. 
When  the  sysem  is  to  be  developed  and  built  by  a  contractor,  preliminary 
work  on  Requests  For  Proposals  (RFPS)  Is  also  undertaken  during  the  demon¬ 
stration  and  validation  phase.  Contracts  may  be  let  for  software  engineer¬ 
ing  support,  such  as  manpower  determinations  and  design  rationale  studies. 
It  is  easy  to  conclude  that  the  human  factors  engineer  should  have  a  key 
role  in  these  activities. 


(Go  on  to  the  next  page) 
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From  Page  36 


Of  particular  interest  to  the  human  factors  engineers  during  this 
phase  is  the  development  and  issuance  of  the  Training  Device  Requirement 
(TDR)  (or  TD  Letter  Requirement  [TDLR]  for  lesser  acquisitions).  These 
documents  state  the  operational,  technical,  and  cost  information  for  train¬ 
ing  device  needs  and  provide  guidance  on  how  training  needs  are  to  be  met . 
The  human  factors  engineer  should  have  a  strong  input  to  the  TDR,  particu¬ 
larly  with  regard  to  human  engineering  characteristics  and  needs.  All  the 
documents  prepared  so  far  should  emphasize  system  effectiveness,  human 
performance  reliability,  and  personnel  requirements.  They  should  embody  the 
results  of  previously  accomplished  analyses  and  point  the  way  to  employment 
of  human  engineering  standards  and  practices  in  the  development  and  pro¬ 
duction  of  the  systems  under  development. 

It  is  during  the  demonstration  and  validation  phase  that  an  advanced 
prototype  or  brassboard  is  developed.  TM  29-76  presents  such  a  brassboard 
on  pages  93  and  94.  As  you  can  see,  this  is  a  functional  mock-up  which 
allows  the  operators  to  actually  perform  tasks  as  they  would  on  the  job. 
Using  such  prototypes,  final  adjustments  in  equipment  design  can  be  made 
and  additional  training  requirements  can  be  defined  prior  to  awarding  con¬ 
tracts  for  full-scale  development.  The  objective  of  the  demonstration  and 
validation  phase  is  met  if  there  is  sufficient  confidence  that  the  program 
worth  and  readiness  warrant  commitment  of  resources  for  full-scale  develop¬ 
ment  and  constitute  a  basis  for  the  award  of  an  enforceable  contract. 

'Full  scale  engineering  development'  is  the  third  phase  of  the  acqui¬ 
sition  process.  It  begins  with  the  awarding  of  development  and  construction 
contracts  and  ends  with  the  acceptance  of  a  prototype  of  the  system  being 
developed.  During  this  y* ase  the  system  design  progresses  from  approved 
detailed  contract  design  specifications  through  detailed  design  drawings 
requisite  to  production  of  mock-ups  (where  required)  and  prototype  systems. 
Activity  in  this  phase  is  not  complete  until  appropriate  solutions  to  the 
problems  associated  with  the  system  (including  such  issues  as  logistics 
support,  production,  maintenance,  and  facilities)  are  obtained. 


(Go  on  to  the  next  page) 
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From  Page  37 


'Production  and  deployment'  Is  the  final  major  phase  In  DOD  system 
acquisition.  During  this  phase  the  system  Is  manufactured,  the  Initial  re¬ 
quired  personnel  training  Is  completed,  provisions  for  logistic  support  are 
finalized,  and  the  entire  system  Is  tested  and  subsequently  made  operation¬ 
al.  Although  the  manager  charged  with  the  systems  acquisition  project  con¬ 
tinues  to  monitor  the  process  after  production  is  underway  and  systems  are 
deployed,  the  formal  weapon  systems  acquisition  process  Is  completed  at 
this  point. 

During  which  of  the  acquisition  phases  Is  it  necessary  to  establish 
the  anticipated  functions,  capabilities,  and  endurance  requirements  of 
weapons  systems? 

(1)  During  the  contract  aware  phase,  which  clarifies  just  what  is  expected 
of  the  manufacturer.  Turn  to  Page  81. 

(2)  During  the  concept  exploration  phase,  when  top  level  specifications  are 
defined  to  match  top  level  requirements.  Turn  to  Page  43. 

(3)  During  the  demonstration  and  validation  phase,  when  engineering  charac¬ 
teristics  are  defined  and  evaluated.  Turn  to  Page  57. 


From  Page  86 


(3)  This  is  only  partially  correct.  Information  processing  Is  only  one  type 
of  human  performance.  In  a  systems  analysis  we  wouldn't  limit  our  findings 
just  to  this  human  performance.  The  correct  answer  is  stated  more  broadly 
than  this  one.  Return  to  Page  86. 
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From  Page  14 


(3)  Now,  we  wouldn't  be  into  a  systems  analysis  if  the  mission  weren’t  re¬ 
quired.  The  conception  of  the  system  was  predicated  upon  a  need  for  that 
system.  Try  again.  Return  to  Page  14. 


From  Page  84 


(4)  Sorry,  but  only  one  of  these  answers  is  correct.  Try  again  on  Page  84. 


From  Page  96 


(3)  You  are  partially  right  here;  some  programs  do  exist  that  provide  input 
to  the  trade-off  decisions.  A  large  measure  of  the  problem  solution  is 
being  able  to  identify  (in  advance)  the  questions  that  need  to  be  asked. 
Return  to  Page  96. 


From  Page  95 


(2)  Not  quite.  At  this  gross  level  of  activity,  estimated  software  should 
not  be  singled  out  from  the  major  factors  it  supports.  A  more  important 
item  is  not  mentioned  in  this  choice.  Return  to  Page  95. 
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From  Page  43 


(1)  Exactly.  When  we  lose  sight  of  the  need  for  Integrated  efforts.  Engi¬ 
neering  decisions  that  are  not  analyzed  for  their  human  Impact  may  become 
quite  expensive  from  the  standpoint  of  overall  system  effectiveness. 

While  Human  Factors  should  be  a  primary  consideration  from  the  outset 
of  the  system  acquisition  process,  too  often  the  only  concession  to  human 
engineering  is  to  apply  lessons  learned  through  experience. 

Following  the  classical  pattern  of  Industrial  human  engineering,  the 
first  opportunity  for  active  participation  by  the  Human  Factors  engineer  is 
normally  identified  as  part  of  the  preliminary  design  effort  in  the  demon¬ 
stration  and  validation  phase.  This  participation  typically  is  manifested 
in  a  development  Request  For  Proposal  (RFP)  which  may  be  distributed  to 
internal  agencies  responsible  for  systems  development.  More  typically,  re¬ 
quests  for  proposals  or  similar  instruments  are  distributed  within  the  pri¬ 
vate  sector  of  Industry  in  order  to  elicit  responses  in  the  form  of  a  pro¬ 
posed  technical  approach  which  would  best  satisfy  the  government's  needs. 
In  turn,  the  probable  response  of  the  typical  engineering-oriented  firm  is 
to  establish  a  'proposed  team'  which  includes  a  human  factors  engineer  or 
someone  responsible  for  human  engineering  impacts. 

As  it  is  most  commonly  practiced  today,  the  preparation  of  a  proposal 
is,  in  effect,  a  preliminary  design  activity.  Many  crucial  engineering 
design  decisions  are  made  during  this  activity,  never  to  be  changed  again, 
simply  because  human  engineering  needs  are  not  fully  anticipated  in  the  RFP 
development.  This  is  typically  the  case  when  a  provision  of  a  system  design 
is  a  specific  parameter  of  the  contractor's  bid.  Quite  bluntly  stated,  if 
the  human  factors  engineer  is  not  permitted  to  provide  inputs  during  both 
RFP  development  and  technical  evaluation  of  the  bids,  then  total  positive 
HFE  influence  on  the  final  version  of  the  equipment  or  system  is  likely  to 
be  greatly  compromised. 

In  some  cases,  specific  design  decisions  may  be  allocated  to  the  human 
factors  engineer.  Controls/display  panel  design  and  work  space  layout  are 
good  examples  of  design  responsibilities  assigned  directly  to  the  Human 
Factors  engineer.  Typically,  other  members  of  the  team  will  be  tasked  to 
work  out  the  details  of  how  the  human  factors  requirements  can  be  imple¬ 
mented  . 


(Go  on  to  the  next  page) 
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From  Page  40 
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In  most  cases  of  design  development,  the  human  factors  engineer  will 
function  in  an  advisory  capacity,  volunteering  information,  or  responding 
to  direct  questions  which  will  influence  the  design  decisions.  Thus,  we  can 
look  at  the  role  of  the  human  factors  engineer  in  the  systems  acquisition/ 
development  process  as  being  primarily  that  of  a  collector,  organizer,  and 
provider  of  Information  in  a  decision-making/problem-solving  situation.  His 
job  is  to  represent  the  potential  users  in  the  acqulsiton  process. 

So,  you  know  that  we  need  human  factors  specialists  as  team  members 
from  the  very  beginning  of  the  system  acqulsiton  process.  Now,  at  what 
point  in  the  life-cycle  of  a  piece  of  equipment  is  the  Human  Factors  spe¬ 
cialist  finished? 

(1)  After  the  engineering-development  prototype  phase.  Turn  to  Page  12. 

(2)  After  the  production  and  deployment  phase  is  completed.  Turn  to  Page 
96. 

(3)  Most  often,  after  the  full-scale  development  phase.  Turn  to  Page  75. 

(4)  There  is  no  correct  answer  provided.  Turn  to  Page  79. 


From  Page  48 


(2)  While  this  answer  is  indeed  an  operational  performance  requirement,  it 
is  not  necessarily  the  only,  or  best  answer.  Return  to  Page  48. 
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From  Page  4 


(4)  Well,  we  almost  hate  to  tell  you  you're  incorrect.  Probability  of  suc¬ 
cess  is  one  form  for  specifying  human  performance  standards.  Time  is  part 
of  another  form.  Time  also  is  an  attribute  of  performance.  This  question 
deals  only  with  performance  characteristics,  not  standards.  Please  try 
again.  Return  to  Page  4. 


From  Page  54 


(3)  While  this  is  a  good  design  consideration  and  may  encourage  positive 
transfer,  it  is  not  the  best  answer.  Return  to  Page  54. 


From  Page  31 


(4)  If  you  got  all  the  information  you  needed  from  the  inventory,  you 
wouldn't  need  to  conduct  a  task  analysis,  would  you?  Return  to  Page  31. 


(2)  Exactly  right.  The  conceptual  generation  of  what  is  expected  of  a  sys¬ 
tem  is  recorded  as  its  Required  Operational  Capability  (ROC)  during  this 
phase. 

Now  that  you  have  a  feel  for  the  acquisition  cycle,  we  need  to  identi¬ 
fy  some  of  the  specific  human  factors  issues  which  must  be  explored  during 
systems  acquisition. 

DOD  mandates  through  MIL-H-46855  that  human  engineering  shall  be  ap¬ 
plied  during  development  and  acquisition  of  military  systems,  equipment, 
and  facilities  to  realize  an  effective  integration  of  personnel  into  the 
design  of  a  system.  This  effort  is  undertaken  in  order  -to  develop  or  im¬ 
prove  upon  the  crew-equipment/sof tware  interface.  The  task  analysis  speci¬ 
fies  which  levels  of  human  performance  are  defined  during  the  operation, 
control,  maintenance,  and  upkeep  of  the  system.  The  human  engineering  ef¬ 
fort  includes,  but  is  not  necessarily  limited  to,  three  major  interrelated 
areas  of  systems  development;  namely,  analysis,  design  and  development,  and 
test  and  evaluation. 

From  what  has  been  revealed  so  far,  what  can  you  conclude  about  which 
stage  in  acquisition  the  human  engineering  efforts  should  be  instituted? 

(1)  It  must  be  an  Integral  part  of  the  whole  acquisition  process  as  it 
evolves.  Turn  to  Page  40. 

(2)  It  is  a  parallel  program  that  assesses  effectiveness  in  meeting  inte¬ 
gration  objectives  as  each  phase  of  acquisition  is  completed.  Turn  to  Page 
80. 

(3)  Human  engineering  relates  primarily  to  the  'man'  side  of  the  man/ 
machine  equation.  Human  Factors  should  not  directly  impact  on  system  devel¬ 
opment.  Turn  to  Page  75. 


From  Page  54 


(2)  That  is  not  the  correct  answer.  One  task  inventory  can  be  used  for  more 
than  one  purpose.  Turn  again  to  Page  54  and  select  another  answer. 


From  Page  83 


(1)  Right  on.  If  we  had  said  'how  the  person  performs  with  the  equipment,  ' 
then  these  answers  would  have  been  right.  You're  100  percent  correct;  none 
of  these  answers  is  totally  correct. 

So,  now  you  know  that  in  test  and  evaluation,  the  idea  is  to  determine 
whether  or  not  a  trained  person  can  perform  assigned  tasks  in  the  system; 
and  if  so,  to  what  level  of  proficiency.  Test  and  evaluation  also  is  done 
to  determine  the  extent  to  which  human  performance  Is  affected  by  the 
equipment  configuration  and  by  other  system  personnel  (if  any).  Finally, 
test  and  evaluation  seeks  to  assess  the  effect  of  human  performance  on  sys¬ 
tem  performance. 

To  accomplish  these  purposes,  it  is  necessary  to  know  about  critical 
tasks  (tasks  which,  if  not  correctly  performed,  result  in  failure  of  the 
system's  mission,  equipment  damage,  or  serious  personal  injury).  You  also 
need  to  know  the  performance  criteria  (performance  standards)  for  those 
tasks.  These  criteria  should  be  quantitative,  such  as  time  and  error  fre¬ 
quency  or  magnitude  values. 

The  next  outcome  of  task  analysis  is  manning.  Task  analysis  for  man¬ 
ning  is  aimed  at  describing  quantitative  and  qualitative  (how  many  and 
which  kind)  personnel  requirements  information  (sometimes  called  'QQPRI' 
for  short).  This  means  that  the  task  analysis  has  to  identify  the  complex¬ 
ity  level  of  tasks  performed  in  the  system,  taking  into  account  the  sys¬ 
tem's  equipment,  operations,  duties,  tasks,  and  environments.  Therefore, 
the  task  analysis  for  manning  needs  to  be  performed  in  such  a  way  that  you 
can  determine  the  functions  of  each  system  component  that  is  human,  the 
relevant  duties  and  tasks  for  those  functions,  along  with  the  time,  loca¬ 
tion,  and  frequency  of  those  duties  and  tasks.  This  information  has  to  be 
organized  in  terms  of  each  person  having  a  job  in  the  system  by  skill 
level.  It  will  then  tell  you  how  many  people  of  each  type,  as  well  as  the 
total,  needed  for  the  system.  This  applies  to  operators  as  well  as  main- 
talners. 

Workload  is  next.  The  task  analysis  for  workload  must  give  information 
to  determine  the  quality  (type  and  category)  of  all  tasks  required  to  oper¬ 
ate  and  maintain  the  system.  The  analysis  also  must  give  information  to 
determine  the  precision  (difficulty  specialization,  performance  criteria), 
quantity,  and  timing  characteristics  of  those  tasks.  Signal  input,  signal 
processing,  and  signal  output  information  are  also  necessary.  The  point  of 
workload  is  the  number  of  tasks  on  a  timeline:  five  tasks  in  an  hour  is  not 
the  same  workload  as  five  tasks  in  1  minute. 

(Go  on  to  the  next  page) 
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From  Page  44 


Okay,  here  we  go.  I'm  going  to  rev  up  ny  micro-circuits,  capacitors, 
diodes,  and  all  that  kind  of  stuff  to  give  you  not  one,  but  two  questions! 

First,  if  you  do  a  task  analysis  for  test  and  evaluation,  will  you 
have  tested  and  evaluated  the  system  when  that  task  analysis  is  completed? 

(1)  Yes.  Turn  to  Page  63. 

(2)  No.  Turn  to  Page  54. 


From  Page  25 


(3)  That  is  not  the  correct  answer.  It  applies  to  a  task  inventory,  but  not 
to  stage  one,  which  deals  with  the  critical  tasks  that  have  been  selected 
from  the  task  inventory.  Return  to  Page  25  and  try  again. 


From  Page  84 


(3)  Very  good,  you  are  right.  Since  the  system  changes  over  time,  the  re¬ 
quirements  of  the  output  categories  will  change  also.  The  information  they 
contain  can  be  added  to  the  inputs  of  task  analysis,  and  as  the  life-cycle 
phase  changes,  the  whole  process  can  begin  again. 

Hell,  we  have  almost  come  to  the  end  of  the  road,  so  to  speak.  This 
lesson  primarily  has  been  devoted  to  the  theoretical  aspects  of  task  analy¬ 
sis.  In  Lesson  24  we  will  give  you  a  bit  more  'hands  on  experience.'  So 
refresh  yourself  in  the  interim,  but  come  back  soon  for... Lesson  24,  Task 
Analysis  II,  or  when  is  an  SBO  not  an  SBO?  Between  now  and  Lesson  24, 
please  become  more  familiar  with  the  supplemental  information  in  Table  23.1 
and  the  DIDS  on  Pages  61  through  64.  See  you. 
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HUMAN  FACTORS  ENGINEERING 


LESSON  24:  TASK  ANALYSIS  II 


Hi,  welcome  back.  This  is-T.esson  24  of ^your  Human  Factors  Engineering 
CoursAy  In  this  lesson,  yoif^fill  finish  the  topic  of  task  analysis^  but... 
you  probably  will  never  finish.  Learning  all  there  is  to  know  ab<?ut  task 
analysis  in  'real  life,'  so  to  speak.  - """ 


\ 

'One  of  the  purposes  of  task  analysis  is  to  ensure  that  all  the  human 
performance  requirements  for  a  new  man-machine  system  have  been  identified v 
This  has  great  practical  importance:  if  the  individual  needs  three  hands 
and  the  strength  of  Godzilla,  we  want  to  know  this  before  we  build  the  sys¬ 
tem,  not  after.  However,  to  know  those  requirements  we  need  to  have  stand¬ 
ardized  definitions  for  the  components  of  task  analysis. 


In  Lesson  23  you  learned  some  of  the  history  and  theory  behind  task 
analysis.  In  that  lesson,  which  of  the  following  was  said  to  be  one  of  the 
biggest  problems  that  surrounds  task  analysis? 

(1)  Lack  of  a  uniform  definition  of  task  analysis.  Turn  to  Page  6.  N 

(2)  Lack  of  a  uniform  definition  of  a  task.  Turn  to  Page  30. 

(3)  Lack  of  a  uniform  definition  of  a  task  inventory.  Turn  to  Page  76. 

(4)  Lack  of  a  uniform.  Turn  to  Page  84.  v 


From  Page  16 


(4)  Wrong.  When  a  system  is  accepted,  there  is  still  provision  to  make 
changes  where  mandated,  but  manpower  characteristics  are  supposed  to  be 
integrated  into  the  initial  design — not  added  afterwards.  Return  to  Page 
16. 


From  Page  26 


(4)  Sorry,  but  you're  incorrect  in  assuming  that  all  of  these  processes  are 
Involved  in  function  analysis.  Return  to  Page  26. 
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From  Page  5 


(2)  You're  only  thinking  of  the  small  picture.  This  is  only  one  example  of 
a  factor  which  can  influence  performance.  Think  big!!  Return  to  Page  5. 


From  Page  75 


(1)  Engaging  the  gas  pedal  is  a  subtask.  It  is  only  one  of  a  number  of  sub¬ 
tasks  that  must  be  performed  to  accomplish  the  task.  You  need  to  look  for 
the  smallest  unit  of  behavior  to  select  a  task  element.  Return  to  Page  75. 


From  Page  66 


(3)  This  may  be  true,  but  in  the  long  run  the  obtained  information  will  be 
of  more  value  than  the  short  production  disruption.  There  is  a  more  serious 
limitation  than  this.  Return  to  Page  66. 
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From  Page  15 


(3)  Good  show.  That's  just  what  we  were  looking  for.  You  were  able  to  fig¬ 
ure  out  that  the  diagram  starts  at  about  9  o'clock.  Recognizing  that  a 
problem  exists  and  can  be  dealt  with  appropriately  is  an  Important  first 
step  In  the  process. 

Once  you  have  recognized  the  problem  and  concluded  that  It  Is  one 
which  you  can  resolve  (you've  done  this  through  preliminary  studies  and 
basic  research),  your  job  has  just  begun.  As  a  human  factors  specialist, 
you  will  want  to  determine  other  aspects  of  the  system  to  be  analyzed,  such 
as  system  requirements  and  constraints.  System  requirements  are  objectives 
that  must  be  met  and  include  things  such  as  the  mission  or  purpose  of  the 
whole  system  and  the  operational  performance  requirements  which  detail  the 
specific  goals,  objectives,  and  standards  of  the  system's  mission.  (See 
Figure  22.2  for  an  example  of  a  system  requirement  block  diagram.)  The 
specific  system  requirements  for  a  given  system  should  be  Included  In  the 
materiel  acquisition  documents  for  that  system.  System  constraints  are 
limits  within  which  the  objectives  must  be  accomplished.  Constraints  In¬ 
clude  cost  and  time  limits  as  well  as  environmental  and  resource  limits. 

Now,  given  what  we  have  just  been  talking  about,  if  your  mission  ob¬ 
jective  was  to  'send  a  space  vehicle  Into  orbit,'  what  would  you  think  some 
of  the  performance  requirements  might  be? 

(1)  The  vehicle  must  be  capable  of  sustaining  a  crew  of  three  members.  Turn 
to  Page  3. 

(2)  The  vehicle  must  attain  a  planned  earth  orbit  at  an  altitude  of  300 
nautical  miles.  Turn  to  Page  41. 

(3)  The  system  must  produce  permanent  scientific  photographic  recordings  of 
the  earth's  geography.  Turn  to  Page  6. 

(4)  All  of  these  answers  are  examples  of  operational  performance  require¬ 
ments.  Turn  to  Page  86. 
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From  Page  11 


(1)  Right,  very  good.  Most  of  the  operations  we  perform  require  some  amount 
of  judgment.  However,  this  type  of  factor  is  not  readily  measured  and, 
often,  it  is  not  included  in  an  analysis  of  basic  tasks. 

The  command  for  which  you  are  working  may  have  a  completely  different 
type  of  form,  but  it  will  be  built  on  the  ideas  we  have  discussed.  At  your 
convenience,  it  would  be  a  good  idea  if  you  took  a  look  at  the  forms  that 
your  particular  command  uses  so  that  you  will  become  readily  familiar  with 
them.  Then,  when  you  are  required  to  use  them,  you  will  not  have  to  study 
them  while  conducting  a  task  analysis.  No  matter  what  type  of  form  is  used, 
it  is  best  to  keep  a  standardized  format.  In  this  way,  it  can  be  kept  as  a 
permanent  record  and  can  be  revised  as  the  task  is  altered. 

Another  type  of  worksheet  is  that  of  Figure  24.3.  This  subdivides  each 
task  into  its  subtasks  and  provides  space  for  recording  time  and  error  in¬ 
formation.  This  type  of  data  sheet  would  be  very  useful  when  doing  task 
analysis  for  test  and  evaluation  and  for  determining  human  performance 
reliability.  This  example  was  taken  from  HEL  TM  22-74.  If  you're  interested 
and  have  time  after  this  lesson,  try  to  get  this  document  and  look  through 
it.  There  is  some  valuable  information  in  it. 

A  document  used  by  the  Navy  for  assessing  how  well  an  operator  can  use 
a  system  in  terms  of  workload  rather  than  design  is  called  MOAT.  This  docu¬ 
ment,  as  well  as  others,  is  defined  and  discussed  in  Lesson  37  of  this 
course.  The  worksheets  discussed  so  far  have  required  a  manual  method  for 
conducting  task  analyses.  To  be  sure,  the  human  must  still  collect  the  data 
by  using  the  observation  techniques  already  discussed;  however,  the  com¬ 
puter  is  an  invaluable  aid  in  summarizing  and  analyzing  this  data.  One  ex¬ 
ample  of  the  interaction  of  manual  and  computer-assisted  task  analysis  is 
LSAR. 


LSAR  is  the  acronym  used  for  the  Logistics  Support  Analysis  Report. 
Two  examples  of  LSAR  data  sheets  are  in  your  supplement  as  Figures  24.4  and 
24.5.  Figure  24.4  is  an  example  of  the  data  analysis  sheet  that  the  analyst 
used  when  doing  the  task  analysis.  It  provides  a  description  of  the  tasks 
and  subtasks  as  they  occur.  For  example,  the  first  activity  was  the  removal 
of  the  front  seat  retaining  pins.  This  took  15  minutes.  Figure  24.4  con¬ 
tains  the  same  information  as  Figure  24.3,  but  this  time  the  information 
has  been  coded  to  conform  to  the  LSAR  computer  format.  Eventually,  we 
expect  LSAR  to  be  modified  so  that  HFE  task  analysis  information  will  be 
presented  as  in  Figure  24.6. 

(Go  on  to  the  next  page) 
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Remember  the  outcome  of  task  analysis?  Design,  training...?  Well, 
using  Figure  24.6,  which  of  the  task  analysis  outcomes  is  best  served  by  an 
output  such  as  24.6? 

(1)  Figure  24.6  provides  data  which  can  be  used  for  all  outcomes.  Turn  to 
Page  23. 

(2)  This  figure  (24.6)  best  represents  a  task  analysis  done  for  design  pur¬ 
poses.  Turn  to  page  34. 

(3)  Figure  24.6  is  primarily  a  task  inventory,  not  a  task  analysis.  Turn 
to  Page  63. 

(4)  None  of  these  answers  represents  Figure  24.6.  Turn  to  Page  99. 


From  Page  69 


(3)  The  function  was  listed  in  Column  1.  Sorry.  Try  again  on  Page  69. 
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(3)  Yes,  the  more  he  knows  about  all  aspects  of  the  environment (s)  the  sys¬ 
tem  will  be  operated  and  maintained  In,  and  by  whom,  the  higher  the  valid¬ 
ity  of  his  Input  is  likely  to  be.  And  not  only  that,  the  HFE  should  work  In 
concert  with  others  on  the  design  team  in  an  atmosphere  of  give  and  take 
where  all  may  contribute  to  achieving  all  design  objectives  In  an  efficient 
manner . 

Now,  you  will  learn  a  little  more  about  the  development  of  prototypes. 
Remember,  we  discussed  these  earlier  in  the  lesson  and  distinguished  be¬ 
tween  breadboard  and  brassboard  prototypes.  Mock-ups  are  not  evaluated  as 
products  themselves,  but  rather  they  are  used  as  tools  to  evaluate  equip¬ 
ment  or  systems  before  they  are  actually  constructed.  These  mock-ups  are 
three  dimensional,  full-scale  models  which  may  be  either  static  or  func¬ 
tional.  Statis  mock-ups  are  usually  constructed  to  size  from  inexpensive 
materials  such  as  cardboard  or  fiberglass,  with  all  major  components  repre¬ 
sented  by  controls,  pictures,  drawings,  and  the  like.  A  functional  mock-up, 
as  the  name  implies,  can  operate  in  a  quasi-functional  manner.  It  has  dis¬ 
plays  that  move  in  response  to  control  actions  and/or  to  simulated  outside 
actions. 

A  fundamentally  important  purpose  of  mock-ups  is  to  verify  the  HPR  and 
the  personnel  selection  standards.  This  is  accomplished  by  having  operators 
go  through  motions  they  will  perform  in  carrying  out  their  duties  in  order 
to  discover  any  potential  difficulties.  Mock-ups  not  only  help  in  getting  a 
'feel'  for  the  system,  they  are  also  potentially  valuable  in  documenting 
the  evolution  of  the  design  and  as  presentation  models  showing  design 
progress.  In  addition,  mock-ups  serve  as  a  training  aid  for  familiarizing 
prospective  operators.  The  human  factors  engineer  can  use  the  mock-up  for 
observational  evaluations,  and  use  checklists  and  tabled  values  to  estimate 
the  value  of  alternative  designs.  Mock-ups  may  also  be  used  for  having 
'operators'  go  through  a  series  of  preselected,  representative  tasks  in 
order  to  determine  whether  the  operator  can  perform  his  assigned  tasks 
within  the  prescribed  human  performance  requirements  as  defined  by  time  and 
error  standards.  Additionally,  functional  mock-ups,  by  reason  of  their 
built-in  capability  to  simulate  operational  characteristics,  provide  a 
laboratory  setting  in  which  to  conduct  Development  Test  I. 


(Go  on  to  the  next  page) 
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With  this  background  In  mock-up  theory,  try  the  following  question. 
Why  should  a  mock-up  be  built  If  all  the  reasons  for  Its  existence  can  be 
accomplished  on  the  equipment  Itself? 

(1)  To  confirm  that  the  HPR  are  feasible,  that  the  personnel  selection 
criteria  are  appropriate,  and  that  the  operations  and  maintenance  training 
burdens  are  sustainable.  Turn  to  Page  84. 

(2)  Mock-ups  can  provide  a  valuable,  yet  relatively  inexpensive,  opportun¬ 
ity  to  gain  assurance  that  the  system  design  is  a  good  one .  Turn  to  Page 
6. 

(3)  The  mock-up  is  a  flexible  and  valuable  tool  that  can  serve  to  support  a 
myriad  of  functions  from  training  to  public  relations.  Turn  to  Page  32. 

(4)  All  the  answers  listed  here  are  true.  Turn  to  Page  16. 


From  Page  72 


(4)  Workload  requirements  are  probably  some  of  the  most  changing  para¬ 
meters.  The  Idea  is  to  reduce  them,  if  possible.  Try  again,  my  friend. 
Return  to  Page  72. 
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From  Page  64 


Wait  a  nanosecond,  we're  searching. 

Oh!  There  they  are! 

The  following  case  history  is  from  years  ago  when  outboard  motor  boats 
were  first  developed.  They  were  fun  to  operate  even  though  they  did  not 
have  a  steering  wheel.  To  steer  the  boat  in  those  days,  the  operator  would 
be  at  the  back  of  the  boat  and  work  the  tiller.  Pulling  the  tiller  handle 
to  the  left  moved  the  boat's  rudder  so  that  the  boat  turned  to  the  right. 
Most  boat  operators  were  accustomed  to  that  arrangement,  because  that  is 
all  that  was  available  at  the  time. 

Then,  someone  got  the  idea  of  attaching  ropes  directly  from  the  handle 
of  the  tiller  assembly  to  a  steering  wheel  placed  at  the  front  of  the  boat. 
The  rest  of  the  system  was  the  same  as  before:  turn  the  wheel  to  the  left 
to  go  right.  That  system  became  instantly  popular  because  it  resembled 
driving  a  car;  however,  there  was  a  serious  problem  with  that  system.  It 
resembled  driving  a  car  in  most  respects,  except  for  one  important  feature. 
The  driver  had  to  turn  the  steering  wheel  in  the  direction  opposite  to  the 
one  he  or  she  wanted  to  go  in.  It  was  opposite  to  the  car  driving  system 
and  it  led  to  collisions,  because  people  were  getting  their  car  driving 
habits  mixed  up  with  boat  driving. 

When  designing  systems  such  as  the  boat's  steering  system  and  when 
designing  training  programs,  it  is  Important  to  consider  the  concept  of 
transfer  of  training.  This  concept  takes  into  account  the  past  training 
and/or  experience  of  the  typical  user.  When  things  that  an  Individual  has 
learned  in  the  past  carry  over  and  are  beneficial  in  later  situations,  we 
say  'positive  transfer'  has  occurred.  The  opposite,  of  course,  is  'negative 
transfer'  and  that  is  what  occurred  with  the  example  you  just  read. 

That  steering  system  design  discussed  above  had  an  adverse  effect  on 
human  performance,  to  say  the  least,  until  someone  figured  out  how  to  ar¬ 
range  the  ropes  from  the  tiller  to  the  wheel  so  that  a  right  turn  of  the 
wheel  would  make  the  boat  turn  to  the  right.  The  person  who  first  designed 
the  steering  wheel  system  failed  to  take  important  human  factors  into  ac¬ 
count  early  in  the  game. 
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So,  you  now  know  that  when  designing  systems  it  is  important  to  take 
into  account  negative  and  positive  transfer  effects.  In  your  past  lessons 
you  learned  a  good  deal  about  the  proper  design  of  displays  and  controls. 
With  this  Information  in  mind,  answer  the  following  question:  Which  of  the 
answers  below  best  relates  to  positive  and  negative  transfer? 

(1)  The  use  of  population  stereotypes  in  equipment  design.  Turn  to  Page 
90. 

(2)  The  use  of  shape  coding  in  control  design.  Turn  to  Page  34. 

(3)  The  use  of  auditory  signals  to  relieve  the  overburdened  visual  system. 
Turn  to  Page  42. 

(4)  All  of  these  are  good  design  considerations  which  relate  to  positive 
and  negative  transfer.  Turn  to  Page  80. 


From  Page  45 


(2)  Congratulations.  'No'  is  the  correct  answer.  The  task  analysis  would 
provide  information  to  facilitate  doing  a  first  rate  job  on  test  and  evalu¬ 
ation,  but  would  not  do  the  testing  or  evaluating  itself.  You  also  know 
that  this  same  principle  applies  to  the  other  four  purposes  of  task  analy¬ 
sis  (design,  training,  manning,  and  workload),  as  well. 

Now,  can  one  task  inventory  be  done  for  more  than  one  analysis  purpose 
(design,  training,  test  and  evaluation,  manning,  workload),  or  must  a 
separate  inventory  be  constructed? 

(1)  One  task  inventory  can  be  used  for  more  than  one  purpose.  Turn  to  Page 
84. 

(2)  A  separate  task  inventory  must  be  constructed  for  each  purpose.  Turn 
to  Page  43. 
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(2)  You've  got  it.  The  first  step  is  to  determine  whether  or  not  the  item 
under  consideration  is  a  candidate  for  trade-off  analysis. 

It  is  not  always  possible  to  achieve  an  optimum  balance  among  possible 
criteria  for  measuring  the  effectiveness  of  a  given  design  of  man-machine 
system;  quite  often  some  give  and  take  must  be  accepted.  Typically,  some 
desirable  features  of  one  design  may  have  to  be  sacrificed,  at  least  in 
part,  to  meet  more  pressing  systems  requirements.  This  is  practically  il¬ 
lustrated  when  the  human  factors  considerations  (which  might  have  made  the 
design  'optimal')  are  traded  off  to  reduce  acquisition  cost.  You,  there¬ 
fore,  need  to  know  how  a  trade-off  is  conducted,  so  that  you  can  defend 
yourself  when  your  program  is  a  candidate  for  being  traded  off. 

There  are  two  families  of  trade-offs  that  may  be  used  in  the  context 
of  this  lesson. 

The  first  trade-off  grouping  encompasses  what  is  called  configuration 
or  geometry  of  design  (this  includes  what  Naval  architects  call  system 
arrangement).  Take  the  complex  design  of  a  warship,  for  example.  The 
spatial  relationships  between  components  and  the  features  which  allow  the 
ship  to  meet  military  readiness  tequlrements  can  become  quite  costly  in 
terms  of  overall  utilization  of  available  resources.  For  example,  increas¬ 
ing  radar  antenna  height  to  clear  surrounding  obstructions  raises  the 
ship's  center  of  gravity  and,  therefore,  makes  it  less  stable  in  the  water. 
While  the  requirement  to  have  unenclosed  space  around  the  antenna  may  be  of 
vital  concern,  unfortunately,  all  of  the  antenna  must  have  ship  under  it, 
and  ships  are  expensive  to  build. 

Another  shipboard  example  can  be  found  in  the  mounting  of  weapons.  Re¬ 
ducing  the  size  and  number  of  sectors  where  weapons  fire  is  blocked  typi¬ 
cally  increases  the  ship's  length.  There  is  usually  a  price  to  be  paid  in 
size,  weight,  or  dollars  in  return  for  broad  margins  of  safety  in  opera¬ 
tion.  In  addition  to  these  trade-offs  which  relate  to  mission  performance, 
many  Internal  arrangements,  although  desirable  from  a  human  engineering 
standpoint,  can  have  significant  Impact  on  warship  size,  weight,  and  cost. 
We  are  often  called  upon  to  answer  questions  such  as,  'how  much  would  your 
HF  design  change  proposal  cost,  and  is  it  worth  that  much?" 

The  second  family  of  design  trade-offs  is  related  to  manpower  alloca¬ 
tions.  Different  operating  requirements,  safety  margin  requirements  of  a 
system,  and  a  need  to  be  operationally  self-sufficient  are  examples  of 
questions  that  typically  result  in  trade-offs  among  qualitative  and  quanti¬ 
tative  manpower  alternatives.  Manpower  trade-off  considerations  can  be  both 
far  reaching  and  sensitive.  Nowhere  is  this  sensitivity  more  obvious  than 


(Go  on  to  the  next  page) 
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in  the  area  of  automation.  For  example,  as  engineering  capabilities  simpli¬ 
fy  the  operation  of  equipment,  the  problem  of  personnel  selection  and 
training  are  reduced.  On  the  other  hand,  the  maintenance  requirements  of 
such  systems  demand  technicians  who  have  exceptional  performance  capabili¬ 
ties.  Thus,  the  problems  of  selection  and  training  are  increased.  Moreover, 
as  you  know,  all  the  armed  services  are  now  relying  on  volunteers  for  their 
manpower.  So,  instead  of  designing  a  system  and  then  going  out  to  select 
people  to  operate  it,  we  now  need  to  explain  to  designers  the  kind  of 
people  we  have  and  the  skills  they  possess,  and  then  insure  that  the  human 
performance  requirements  of  the  design  do  no  exceed  those  skill  levels. 

Since  most  trade-off  issues  can  be  broadly  grouped  into  two  families, 
doesn't  it  logically  follow  that  design  engineers  should  look  after  the 
hardware  while  human  factors  engineers  concern  themselves  with  manpower 
concerns? 

(1)  Design  engineers  must  always  aim  their  efforts  toward  complementing 
man' 8  needs  so  that  he  can  operate  more  efficiently.  Turn  to  Page  77. 

(2)  This  is  essentially  so,  but  clear  communication  channels  must  be  main¬ 
tained  so  that  the  manpower  people  can  react  in  a  timely  manner.  Turn  to 
Page  83. 

(3)  Not  at  all.  The  trade-off  issues  are  so  intertwined  that  consideration 
needs  to  be  given  to  all  four  factors  (personnel,  training,  equipment,  and 
human  performance  requirements)  when  making  trade-off  decisions.  Turn  to 
Page  71. 


From  Page  29 


(2)  No.  To  start  with,  an  entire  community  of  key  players  has  been  left  out 
here.  Return  to  Page  29  for  another  try. 


From  Page  38 


(3)  True,  engineering  standards  are  defined  during  the  demonstration  and 
validation  phase,  but  first,  top  level  specifications  of  the  overall  sys¬ 
tems  requirements  have  to  be  promulgated  before  they  can  be  refined.  Return 
to  Page  38  and  try  again. 


From  Page  8 


(2)  When  you  modify  a  traditional  system,  a  systems  analysis  Is  by  no  means 
out  of  place,  but  Its  use  Is  more  crucial  elsewhere.  Return  to  Page  8. 


From  Page  29 


(3)  A  series  of  perceptions  about  the  job  might  be  a  part  of  the  task,  but 
only  a  part.  After  all,  if  you  perceive  something  and  then  don't  respond, 
you  probably  haven't  performed  the  task.  Try  again  on  Page  29. 


From  Page  83 


(5)  Sorry,  but  we  fooled  you.  All  of  these  answers  are  correct  only  if  you 
are  referring  to  the  human,  not  the  equipment.  Return  to  Page  83. 
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HUMAN  FACTORS  ENGINEERING 


LESSON  25:  AFFORDABILITY,  OR  ARE  WE  MAKING  THE  RIGHT  CHOICE? 

Let’s  move  right  along;  It’ sNalmost  time  for  class  to  begin.  Today  Dr. 
Ed  U.  Kator  Is  going  to  talk  about-^some  of  the  practical  Issues  that  arise 
In  cost/benefit  trade-offs. 

This  lesson  should  provide  some  insights  into  an  Important  area  where 
system  and  task  analysis  skills  are  typically  put  to  use^ 

-"'X' 

Every  day  each  of  us  is  Involved  In  making  cost/benefit  trade-off  de¬ 
cisions.  In  the  same  regard,  we  also  identify  the  criteria  by  which  these 
decisions  are  made.  For  instance,  when  you  got  dressed  this  morning,  did 
you  look  in  your  closet  and  choose  the  clothing  you  are  wearing?  Was  that 
selection  based  on  a  requirement  to  dress  for  a  conference,  your  mood,  or 
the  fact  that  you  could  only  find  a  clean  shirt  that  went  with  blue  or 
grey?  Regardless,  you  recognized  a  need  to  meet  a  certain  standard  of 
dress;  you  established  a  criterion  for  making  your  selection  (style,  color, 
availability);  and  conducted  an  elementary  trade-off  analysis  based  on 
these  needs,  criteria,  and  alternatives.  All  right,  we  realize  LT  Eager 
just  had  a  choice  of  whether  or  not  to  put  on  a  fresh  uniform.  But  how 
about  lunch  yesterday?  Did  you  stop  by  for  a  burger  or  a  plate  lunch  at  a 
restaurant?  Did  you  bring  in  a  sandwich  or,  simply,  did  you  not  have  time 
enough  to  eat?  Regardless  of  the  criteria-tirae,  availability,  convenience, 
or  cost — the  point  has  been  made  that  we  are  all  experienced  in  trade-off 
analyses. 

In  order  to  meet  the  performance  and  cost  requirements  of  the  mili¬ 
tary,  various  trade-off  analyses  must  be  conducted  throughout  the  system 
acquisition  cycle.  The  initial  and  most  dramatic  trade-off  analyses  are 
conducted  during  the  concept  exploration  phase  of  preliminary  design.  You 
recall  from  your  study  of  the  acquisition  process,  that  an  objective  of  the 
concept  exploration  phase  is  to  satisfy  the  need  for  a  system  in  terms  of 
mission  element  needs  (MENS).  Eventually,  operational  needs  are  defined  in 
terms  of  system  parameters,  such  as  capability,  capacity,  and  endurance, 
which  are  called  the  required  operational  capability  (ROC)  or  top  level 
requirements  (TLR).  Trade-off  analysis  is  a  key  portion  of  the  processes 
involved  in  deciding  which  subsystems  and  components  will  comprise  a  sys¬ 
tem.  For  example,  trade-off  analysis  will  help  provide  answers  to  questions 
such  as,  ’what  fire  control  system  best  meets  the  support  criteria  devel¬ 
oped  for  a  new  version  of  a  new  antiarmor  missile  system?’ 


(Go  on  to  the  next  page) 


58 


From  Page  58 


At  this  point,  what  can  you  conclude  about  how  a  trade-off  analysis 
should  be  undertaken? 

(1)  The  first  step  is  to  put  a  dollar  value  on  all  the  potential  alterna¬ 
tives.  Turn  to  Page  21. 

(2)  The  first  step  in  trade-off  analysis  is  to  establish  why  an  analysis 
should  be  conducted.  Turn  to  Page  55. 

(3)  The  first  step  is  to  list  all  the  functions  assigned  to  man  and/or  to 
machines.  Turn  to  Page  17. 


From  Page  69 


(4)  Good  show,  but  wrong.  However,  we're  glad  to  see  you've  kept  your  sense 
of  humor.  Return  to  Page  69  and  try  again. 


From  Page  11 


(2)  It  isn't  really  necessary  to  judge  the  tightness  of  the  screws.  Go 
back  to  Page  11  and  try  again. 
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(1)  That's  right,  the  actual  application  of  HFE  reflects  the  status  of  the 
system  or  equipment  to  be  procured  and  its  Intended  use. 

Let  us  turn  now  to  an  outline  description  of  the  weapon  system  acqui¬ 
sition  process. 

The  first  step  in  any  acquisition  requiring  operational  development  is 
establishing  the  need  for  a  new  system.  While  present  system  obsolescence 
may  be  considered  to  be  important,  the  fact  that  there  is  a  specific  capa¬ 
bility  need  which  cannot  be  satisfactorily  met  by  current  systems  or  equip¬ 
ment  is  at  the  heart  of  justifying  a  new  acquisition.  The  need  and  justifi¬ 
cation  for  acquisition  must  be  fully  developed  in  a  'Mission  Element  Need 
Statement'  (MENS)  by  the  requirement  originating  activity.  Let  us  assume 
that  the  acquisition  decision  has  been  justified  and  subsequently  approved 
by  the  appropriate  level  of  the  System  Acquisition  Review  Council  (SARC). 
In  so  doing,  the  proposed  system  has  proceeded  from  milestone  zero  into  the 
acquisition  process. 

After  the  need  for  a  new  system  has  been  established,  there  are  four 
major  phases  in  the  military  weapons  system  acquisition  process.  The  first 
three  phases  are  punctuated  by  a  review  and  approval  process. 

The  'concept  exploration  phase'  represents  the  initial  effort  toward 
defining  the  need  for  a  particular  system.  Its  purpose  is  to  establish  in 
broad  terms  the  performance,  cost,  and  schedule  requirements  of  the  system. 
Several  processes  occur  during  the  concept  exploration  phase.  First,  in  the 
materiel  concept  investigation,  the  human  factors  specialist  conducts 
studies  to  determine  the  upper  and  lower  limits  of  acceptable  human  per¬ 
formance,  determines  the  extent  of  the  manpower-equipment  interface,  and 
identifies  human  performance  requirements.  Of  course,  if  the  system  being 
developed  is  new,  these  human  factors  studies  may  be  primarily  conceptual 
in  nature.  That  is,  data  used  in  these  studies  will  have  come  from  other 
systems  which  are  similar  to  this  one.  From  those  data,  determinations  such 
as  the  human  limitations  and  requirements  can  be  estimated. 

Following  the  materiel  concept  investigation,  the  acquisition  team 
establishes  an  overall  conceptual  picture  of  what  the  system  will  be  in 
terms  of  function,  size,  endurance,  and  capabilities  which,  in  total,  com¬ 
prise  the  preliminary  top  level  requirements  expected  of  the  system.  This 
subphase  also  develops  a  conceptual  baseline  and  a  firm  basis  from  which  to 
Initiate  preliminary  system  design. 

(Go  on  to  the  next  page) 
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The  outcome  of  the  concept  exploration  phase  Includes  a  Letter  of 
Agreement  (LOA),  a  document  in  which  the  system  user  and  the  material  de¬ 
veloper  outline  the  basic  agreements  for  further  Investigation.  The  LOA 
documentation  specifies  the  agency  responsible  for  conducting  and  reviewing 
the  HFE  analysis.  Specific  objectives  of  the  analysis  include  identifica¬ 
tion  of  operator  and  maintainer  casks  to  develop  training  requirements; 
identification  of  human  factors  research  required  to  support  the  training 
requirement  and  operating  concept;  and  identification  of  HFE  guideline 
standards,  processes,  and  the  like  necessary  to  ensure  that  operational 
performance  objectives  can  be  met  by  available  personnel.  The  LOA  further 
identifies  training  devices  and  aids  and  special  training  requirements. 
Similar  meterial  is  documented  in  the  Letter  Requirement  (LR),  which  is  an 
abbreviated  version  of  the  LOA  used  for  acquisition  of  low-cost  items. 

The  Outline  Acquisition  Plan  (OAP)  is  a  second  joint  document  devel¬ 
oped  in  conjunction  with  the  LOA.  It  includes  a  plan  for  management  of  the 
Research,  Development,  Test  and  Evaluation  (RDT&E)  effort  needed  to  achieve 
the  materiel  objectives  of  the  LOA.  In  addition,  the  OAP  contains  plans  for 
personnel  and  training  requirements  and  for  logistics  support. 

So,  the  concept  exploration  phase  of  systems  acquisition  is  an  in¬ 
volved  process.  In  your  previous  20  lessons  you  learned  about  the  human  in 
terms  of  anthropometry,  visual  capabilities,  and  so  on.  At  what  point  in 
the  system  acquisition  process  should  information  such  as  anthropometric 
requirements  be  introduced? 

(1)  When  preparing  the  mission  element  need  statement.  Turn  to  Page  36. 

(2)  During  the  first  part  or  materiel  concept  investigation  of  the  concept 
exploration  phase.  Turn  to  Page  17. 

(3)  During  the  experimental  prototype  or  breadboard  phase.  Turn  to  Page 
18. 

(A)  All  of  these  phases  require  knowledge  of  anthropometric  data.  Turn  to 
Page  21 . 
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(2)  Very  good.  You're  absolutely  right.  A  focus  on  cost  effectiveness  is  an 
important  part  of  functional  analysis. 

The  process  of  decomposing  each  mission  into  its  required  function  is 
basically  one  of  logical  analysis.  At  this  point  in  the  systems  analysis 
process,  do  we  need  to  show  which  functions  should  be  assigned  to  the  human 
and  which  to  the  machine? 

(1)  Yes,  this  is  the  essence  of  HFE.  Turn  to  Page  20. 

(2)  No,  it  is  impossible  to  do  this  in  the  early  design  stages.  Turn  to 
Page  65. 

(3)  Of  course.  In  this  way  we  can  determine  human  performance  requirements. 
Turn  to  Page  11. 

(4)  No.  If  we  did,  we  may  unnecessarily  constrain  the  system  design.  Turn 
to  Page  85. 


From  Page  72 


(3)  Life-cycle  cost  is  a  key  parameter  in  trade-off  decision  making,  but 
not  the  baseline  factor  in  the  initial  concept  we  have  outlined.  Return  to 
Page  72. 
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(4)  Sorry,  this  is  a  task  of  a  system.  Return  to  Page  18  and  try  again. 


From  Page  45 


(1)  The  task  analysis  would  not  do  the  testing  or  evaluation  of  the  system. 
Instead,  it  would  generate  Information  needed  to  do  an  effective  job  of 
test  and  evaluation.  This  principle  also  applies  to  the  other  four  purposes 
of  task  analysis  which  we  discussed  (l.e.,  design,  training,  manning,  and 
workload).  Select  another  answer  on  Page  45. 


From  Page  25 


(1)  The  appropriate  sequence  of  tasks  is  important  to  doing  the  job,  but  It 
may  not  be  Important  for  stage  one  purposes.  Return  to  Page  25. 


From  Page  50 


1  (3)  If  you  really  think  this  is  the  correct  answer,  you  haven’t  understood 

these  last  two  lessons  very  well.  That  Is  okay,  because  they  are  difficult, 
but  you  need  to  go  back  over  them  before  proceeding. 
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(3)  Right  on!  Any  inventory  liats  things,  and  a  task  inventory  is  no  dif¬ 
ferent;  it  lists  tasks.  It  lists  all  the  tasks  performed  in  a  job. 

A  'task  taxonomy'  is  a  standard  system  for  classifying  the  activities 
of  a  system  by  the  level  of  detail  of  activities  required.  The  task  tax¬ 
onomy  organization  is  one  that  goes  from  a  large  amount  of  detail  to  a 
small  amount  of  detail.  In  order  of  decreasing  detail  those  levels  are  job, 
duty,  task,  subtask,  and  task  element.  So,  you  can  see  that  using  a  task 
taxonomy  (what  we  call  the  organization  scheme)  to  develop  the  task 
inventory  helps  us  examine  a  large  set  of  tasks  in  a  meaningful  and  orderly 
manner.  A  summary  of  these  important  definitions  is  provided  in  your  sup¬ 
plement  as  Table  23.1 

The  definition  of  task  analysis  also  uses  the  term  'supporting  data.' 
Supporting  data  is  any  Information  which  is  relevant  to  the  task  analysis, 
but  which  is  not  found  in  the  task  inventory.  For  example,  worker  opinions 
and  comments  are  relevant  pieces  of  information.  Suppose  you  were  assigned 
the  job  of  conducting  a  task  analysis  for  a  job  which  was  sweaty  and  dirty. 
After  determining  the  behavior  involved,  you  are  told  by  several  workers 
that  the  dress  code  requirement  will  not  allow  ease  of  movement  and  is, 
therefore,  hampering  performance  and  worker  satisfaction.  This  type  of  in¬ 
formation  is,  indeed,  important  in  your  analysis  of  this  particular  job. 
Another  example  of  supporting  data  is  the  climate  (humidity  and  tempera¬ 
ture)  in  which  the  tasks  have  to  be  performed. 

How  that  we've  covered  most  of  the  terms  found  in  the  definition  of 
task  analysis,  let's  define  it  again  to  see  how  it  appears  together  now. 
Task  analysis  is  an  analytic  process  applied  to  a  task  inventory  and  sup¬ 
porting  data  to  produce  a  description  of  some  aspect  of  the  human  component 
in  a  manned  system,  and  to  provide  Information  for  system  design,  training, 
test  and  evaluation,  manning,  and  workload.  There  you  have  it. 

We  know  that  we  still  have  not  covered  fully  the  entire  definition.  We 
haven't  dealt  with  the  second  part  that  Involves  task  analysis  to  produce 
information  for  system  design,  training,  test  and  evaluation,  manning,  and 
workload.  You  see,  this  part  of  the  definition  of  task  analysis  explains 
its  uses.  And  that  is  the  very  next  section  of  this  lesson. 

Before  continuing,  let  us  dip  into  our  memory  banks  for  two  short  case 
histories  about  how  design  affects  human  performance  and  system  output. 

(Turn  to  Page  53) 
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From  Page  16 


I _ I 

(3)  No,  this  question  should  have  been  resolved  before  the  system  was  ac¬ 
cepted.  Return  to  Page  16. 


From  Page  62 


(2)  Right  answer,  wrong  reason.  It  Isn't  Impossible  to  allocate  functions 
to  both  the  human  and  the  machine,  but  in  the  earliest  design  stages  we 
would  severely  reduce  the  design  options  if  this  were  done.  Return  to  Page 
62. 


From  Page  85 


(2)  Isn’t  this  an  example  of  a  function  required  of  the  system  (chopper)? 
Wouldn't  there  be  a  number  of  tasks  to  be  performed  in  order  to  accomplish 
this  function?  Try  again  please.  Return  to  Page  85. 


From  Page  90 


(4)  Phase  four  is  way  too  late  in  system  development.  But,  unfortunately, 
this  la  often  when  task  analysis  is  conducted.  Return  to  Page  90. 
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(1)  Very  good.  While  this  procedure  can  give  you  valuable  information,  it 
is  only  possible  to  use  it  if  you  yourself  can  perform  the  job.  This  pro¬ 
cedure  may  be  fine  to  use  if  the  job  in  question  is  that  of  truck  driver, 
but  what  if  you’re  analyzing  an  astronaut's  job?  Going  into  space,  are  you? 

Worker  opinions  are  also  useful  sources  of  information;  after  all,  who 
knows  the  job  and  its  tasks  better  than  the  person  who  performs  them. 
Nevertheless,  the  opinions  of  the  job  performer  do  have  limitations.  First, 
the  worker  who  has  been  operating  the  equipment  for  a  long  time  may  have 
become  adapted  to  its  shortcomings,  and  thus,  no  longer  sees  them.  We’ve 
all  had  experience  with  this  phenomenon,  haven't  we?  Next,  the  worker  may 
be  so  used  to  the  way  the  system  works  that  he  is  unable  to  think  of  ways 
to  improve  it. 

Okay,  which  of  the  following  is  another  limitation  of  worker  opinions? 

(1)  The  workers  may  resent  an  analyst  who  tries  to  perform  their  jobs.  Turn 
to  Page  10. 

(2)  The  individual's  complaints  about  the  system  may  be  expressions  of  his 
own  discontent,  and  they  may  not  have  any  relationship  to  the  equipment 
Itself.  Turn  to  Page  25. 

(3)  The  analyst  will  disrupt  team  performance  while  gathering  the  task 
analysis  data.  Turn  to  Page  47. 

(4)  All  of  these.  Turn  to  Page  67. 


From  Page  14 


(4)  The  next  step  just  focuses  on  one  of  these  selections.  Remember,  we 
said  logical  thinking  is  required.  Try  placing  things  in  a  time  framework. 
First,  someone  determined  that  the  system  was  needed.  Then,  its  mission  was 
defined.  Now  we  need  to  know  ...?  Return  to  Page  14. 
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I _ I 

(1)  Very  good,  but  Incorrect.  We  bet  your  task  was  taking  out  the  trash, 
wasn't  it?  Return  to  Page  29. 


From  Page  78 


(2)  This  could  be  a  disadvantage,  but  if  you  can  perform  the  job  in  ques¬ 
tion,  you  could  still  get  the  task  analysis  data  needed.  This  answer  may  be 
more  related  to  productivity  of  the  other  workers  than  it  is  to  gathering 
task  analysis  information.  Return  to  Page  78. 


From  Page  66 


(4)  One  of  these  answers  doesn't  apply  at  all.  Of  the  two  remaining,  one  is 
a  more  serious  limitation  than  the  other  and,  therefore,  is  the  best 
answer.  Try  again  on  Page  66. 
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From  Page  76 


(3)  Exactly.  You  are  correct.  We  congratulate  you.  This  SBO  contains  the 
conditions  of  performance,  the  action  required,  and  the  standard  against 
which  to  judge  successful  performance.  Good  show. 

In  stage  three,  you  identify  the  skills  and  knowledge  relevant  to  each 
SBO.  Although  this  stage  is  sometimes  identified  as  if  it  were  separate  in 
time  from  the  other  two  stages,  in  practice  this  need  not  be.  It  is  often 
possible  to  gather  and  arrange  the  data  for  this  stage  while  completing 
stages  one  or  two. 

One  key  to  developing  supporting  skills  and  knowledge  is  to  examine 
action  verbs  for  the  task  (subtask  or  task  element)  statements  of  stage 
one,  or  the  SBO  statements  of  stage  two.  This  is  because  a  good  action  verb 
will  identify  the  type  of  learning  involved,  such  as  recall,  recognition, 
or  psychomotor  performance.  Here  are  a  few  examples:  list,  recite,  match, 
remove,  lift. 

A  second  key  to  identifying  skills  and  knowledge  is  to  review  avail¬ 
able  literature  and  documentation  (e.g.,  supporting  data)  about  the  job 
being  analyzed.  Supporting  items  may  include  terms,  symbols,  basic  con¬ 
cepts,  location  of  objects,  nomenclature,  procedures  (e.g.,  how  to  read  a 
gas  meter)  or  items  of  information  (e.g.,  about  10  percent  of  the  popula¬ 
tion  anywhere  in  the  world,  civilized  or  primitive,  is  left-handed).  Ex¬ 
amples  of  skills  can  include  such  activities  as  typing,  driving  a  car, 
using  a  voltameter,  riding  a  horse,  waterskiing,  or  tying  your  shoes.  When 
identifying  skills,  you  also  need  to  identify  the  skill  level  or  standard 
required.  For  example,  the  number  of  words  per  minute  required  for  a  typing 
skill. 

Now  that  we  have  covered  the  three  stages  of  task  analysis,  let's  turn 
to  the  mechanics  of  completing  it.  One  of  the  ways  to  document  your  find¬ 
ings  from  a  task  analysis,  as  well  as  providing  you  with  an  organization 
for  performing  the  task  analysis,  is  the  worksheet  that  you  use. 

The  task  analysis  worksheet  should  be  constructed  so  that  the  task  can 
be  broken  down  into  ltB  elements.  Two  examples  of  a  task  analysis  worksheet 
are  provided  in  your  supplement  as  Figures  24.1  and  24.2. 

(Go  on  to  the  next  page) 
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From  Page  68 


Figure  24.1  ia  a  type  of  worksheet  which  provides  information  about 
the  stimulus  which  indicates  that  an  action  is  required  (Column  4).  It  also 
indicates  what  the  required  action  is  (Column  5)  and  the  feedback  which  is 
given,  so  the  operator  knows  whether  or  not  his  action  has  been  correct  or 
incorrect  (Column  6). 

In  this  example.  Column  5  represents  what  we  have  referred  to  as: 

(1)  Subtask.  Turn  to  Page  31. 

(2)  Task  element.  Turn  to  Page  11. 

(3)  Job  function.  Turn  to  Page  50. 

(4)  I.  M.  Eager.  Turn  to  Page  59. 


From  Page  35 


(2)  This  is  a  good  example  of  an  action  statement.  Sorry.  Return  to  Page 
35. 
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(2)  Yes,  and  when  you  Chink  about  the  variety  of  Items  and  systems  to  be 
acquired  and  applied  to  different  uses  by  different  users,  the  required 
procedures  seem  endless.  So,  too,  are  the  human  factors  to  be  considered. 

Each  military  service  has  its  own  detailed  procedures  for  applying 
design  and  testing  of  HFE  to  new  procurements.  When  one  service  acts  to 
develop  and  procure  materiel  or  a  system  needed  by  all  to  satisfy  a  Joint 
Service  Operational  Requirement  (JSOR),  HFE  procedures  applied  may  well  be 
the  total  of  all  the  unique  service  needs. 

The  broadest  governmental  procurement  policy  Is  expressed  In  Circular 
A-109  from  the  Office  of  the  Management  and  Budget.  This  document  seeks  to 
establish  a  common  framework  for  all  acquisition  programs.  It  defines  and 
highlights  key  decisions  to  be  made  and  specifies  governmental  levels  that 
are  responsible  for  making  those  decisions.  Within  the  Department  of  De¬ 
fense,  DOD  Directives  5000.1,  5000.2,  and  5000.3  give  guidance  of  imple¬ 
menting  A-109.  Directive  5000.1  provides  policy  for  acquisition  of  major 
systems  which  exceed  $75  million  for  research  and  $300  million  for  procure¬ 
ment.  Its  main  objectives  are  to  integrate  support,  manpower,  and  other 
concerns  into  the  acquisition  process.  DOD  Directive  5000.2  supplements 
5000.1  by  providing  policies  and  procedures  for  the  system  acquisition 
process. 

Of  course,  once  you  begin  the  acquisition  process,  you  also  begin  the 
list  and  evaluation  process  as  well.  DOD  Directive  5000.3  provides  guidance 
in  this  area.  Test  and  evaluation  is  so  important  that  we  have  included  an 
entire  lesson  (Lesson  37)  devoted  to  this  topic.  Briefly,  however,  test  and 
evaluation  is  conducted  to  assess  and  reduce  risks  and  to  estimate  the  ef¬ 
fectiveness  and  suitability  of  the  developing  system. 

Can  we  assume  that  HFE  is  uniformly  applied  to  all  military  acquisi¬ 
tions? 

(1)  No,  while  some  items  naturally  satisfy  HFE  needs,  others  will  require 
expensive  human  engineering  to  satisfy  human  factors  needs.  Turn  to  Page 
60. 

(2)  No,  the  HFE  effort  is  directly  proportional  to  the  expected  cost  of  the 
acquisition.  Turn  to  Page  26. 

(3)  Yes,  DOD  Directive  5000.1  establishes  HFE  checklists  which  must  be 
satisfied  for  all  acquisitions.  Turn  to  Page  19. 
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(3)  That's  right.  A  change  in  one  of  the  factors  almost  always  causes  a 
change  in  each  of  the  other  thiee.  The  idea  is  to  meet  all  the  performance 
requirements  of  the  system  with  a  cost-effective  design  which  puts  a  mini¬ 
mum  burden  on  the  training  base  and  uses  the  personnel  skills  which  are 
most  available. 

One  of  the  things  we  have  learned  in  this  lesson  is  that  while  the 
type  of  issues  to  be  resolved  in  trade-off  analysis  can  be  grouped,  each 
new  weapon  system  represents  a  unique  range  of  analytical  issues.  Trade¬ 
offs  of  manpower  and  hardware  design  in  one  system  may  revolve  around  al¬ 
ternative  maintenance  concepts,  whereas  in  another  system,  the  issues  may 
relate  to  particular  types  of  personnel  skills  required  by  a  certain  hard¬ 
ware  design.  Thus,  the  development  methodologies  capable  of  resolving  all 
acquisition  problems  are  dependent  upon  knowing  in  advance  all  the  possible 
Issues  related  to  all  the  potential  elements  of  the  system  under  develop¬ 
ment  . 


There  are  no  pat  solution  formulas  to  plug  in,  in  order  to  achieve  the 
best  trade-off  results.  One  objective  of  this  lesson,  therefore,  is  to  out¬ 
line  procedures  and  approaches  that  present  a  frame  work  in  which  specific 
trade-off  analyses  may  be  conducted. 

Figure  25.1  of  your  student  supplement  illustrates  the  general  concept 
of  a  system  trade-off  analysis.  As  you  can  see,  the  operational  require¬ 
ments  are  already  set,  and  they  impinge  on  the  design  team.  Now,  the  team 
must  think  about  and  suggest  hardware  configurations  and  personnel  consid¬ 
erations  which  will  meet  the  requirements  and  which  will  be  cost-effective. 
The  juggling  of  these  two  considerations  (man  and  machine)  is  trade-off 
analysis. 

In  principle,  the  analysis  proceeds  through  several  stages.  As  pre¬ 
viously  indicated,  a  hardware  design  is  postulated  in  response  to  the  oper¬ 
ational  requirement.  Based  on  this  design,  manpower  and  training  require¬ 
ments  are  determined  from  human  performance  requirements  and  a  knowledge  of 
personnel  skills  available. 

At  this  point,  the  team  evaluates  what  they  have  come  up  with.  For 
example,  someone  might  say,  "Hey,  Joe,  this  piece  of  equipment  is  dandy  and 
does  the  job,  but  it  will  require  18  men  to  operate  it.  We  only  have  a  6- 
foot  space  to  contain  the  equipment  and  men.  Now  what?  Do  we  redesign  the 
equipment  so  as  to  allocate  more  functions  to  it  and  not  to  the  men?  Can  we 
train-in  the  necessary  behaviors  so  that  it  will  take  only  four  men  to 
operate  the  machine?  What  are  the  costs  of  these  two  proposals?” 

You  get  the  idea? 


(Go  on  to  the  next  page) 
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The  various  viable  possibilities  Involving  total  capability  and  re¬ 
source  cost  would  be  used  for  determining  the  preferred  alternatives.  Ob¬ 
viously,  the  selection  should  be  based  on  how  well  prespecified  criteria 
are  satisfied.  Manpower  and  training  requirements  may  or  may  not  be  the 
deciding  factor,  but  they  will  be  important  considerations  in  almost  all 
systems  acquisitions.  It  also  has  become  axiomatic  In  the  design  of  mili¬ 
tary  systems  that  overall  personnel  safety  weighs  heavily  In  the  alterna¬ 
tive  system  selection  process. 

What  major  parameter  Is  typically  held  constant  in  the  demonstration 
and  validation  phase  of  trade-off  analyses? 

(1)  Comparable  costs  in  terms  of  man  and  materiel.  Turn  to  Page  73. 

(2)  The  system  capability  to  meet  operational  requirements.  Turn  to  Page 
74. 

(3)  A  specified  level  of  life-cycle  costing  for  an  expected  service  life  of 
the  system.  Turn  to  Page  62. 

(4)  Workload  requirements  for  the  selected  manpower.  Turn  to  Page  52. 
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^  (4)  Very  nice.  All  of  these  factors  are,  indeed,  important  Influences  of 

performance. 

When  we  establish  the  human  performance  requirements,  we  usually  use 
variables  such  as  time  to  complete  a  given  task,  and  number /type  of  per¬ 
formance  errors  which  can  be  tolerated.  The  purpose  of  the  tests  and  evalu¬ 
ations  is  to  insure  that  these  human  performance  requirements  are  met. 

So,  you  can  see  that  HFE  requirements  continue  throughout  the  full 
system  acquisition  cycle  and  service  life  of  the  system. 

The  broad  subject  of  the  role  of  human  factors  engineers  in  systems 
acquisition  has  been  a  lot  to  tackle  at  one  time.  It  is  possible  to  be  more 
detailed  in  aiding  the  human  factors  engineer  than  we  have  been  here.  To 
help  you  learn  more  about  the  system  acquisition  process,  we  recommend  to 
you  a  new  publication  from  the  Human  Engineering  Lab,  Aberdeen.  This  docu¬ 
ment  is  entitled,  'Human  Factors  Engineering  in  Research,  Development,  and 
Acquisition.'  It  shows  you  the  entire  acquisition  process  and  the  HFE  in¬ 
volvement  using  a  flow  diagram  approach.  We  suggest  you  secure  a  copy  and 
spend  a  few  minutes  looking  it  over. 

As  the  closing  bell  is  about  to  ring,  we  want  to  remind  you  of  the 
questions  found  on  Page  54  of  your  student  supplement.  If  you  review  these 
questions,  you  should  have  a  good  grasp  of  the  framework  in  which  we  will 
undertake  systems  analysis  the  next  time  we  meet.  Also,  the  next  lesson's 
supplemental  figures  should  be  reviewed  before  you  tackle  the  text.  See  you 
soon  in  'The  Big  Picture'  (Lesson  22). 
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From  Page  72 


(2)  Right  on  the  head.  All  proposed  system  alternatives  must  meet  opera¬ 
tional  requirements;  that  is,  the  top  level  specifications  for  performance. 

The  trade-off  model  we  have  described  is  logical  and  relatively 
simple.  It  is  easy  to  translate  this  model  into  human  factors  terms.  For 
example,  concerns  such  as  accessibility,  control  configuration,  and  work 
space  design  may  be  assessed  while  maintaining  minimum  performance  as  a 
constant.  Just  how  easy  (or  hard)  it  is  to  do  trade-off  analysis  is  direct¬ 
ly  related  to  the  complexity  of  the  system  under  consideration.  While  the 
approach  may  be  similar,  the  models  required  for  analyzing  development  of  a 
new  radar,  for  instance,  would  be  much  simpler  than  those  required  for 
analyzing  an  entire  mobile  command  post. 

It  is  given,  then,  that  there  cannot  be  one  particular  trade-off  model 
or  single  measurement  concept  that  allows  a  designer  to  conduct  all  trade¬ 
off  analyses.  Each  round  of  analysis  poses  its  unique  analytical  Issues  to 
be  addressed  and  performance  criteria  to  be  met. 

If  no  single  or  related  family  of  models  can  be  employed  to  meet  all 
trade-off  needs,  what  can  we  conclude  to  be  the  key  element  in  designing  a 
specific  trade-off  model? 

(1)  A  knowledge  of  the  human  performance  requirements  of  the  proposed  sys¬ 
tem.  Turn  to  Page  94. 

(2)  The  definition  of  the  hardware  involved  must  be  completed  first.  Turn 
to  Page  100. 

(3)  An  economic  baseline  year  must  be  identified.  Turn  to  Page  98. 

(4)  The  relative  weights  of  measurement  criteria  must  be  decided.  Turn  to 
Page  20. 
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From  Page  18 
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(1)  Very  good.  The  only  function  of  this  system  shown  above  is  to  drive  the 
I  truck. 

So,  now  you  know  the  mission  and  the  function  of  the  man-machine  sys- 
1  tem.  The  job  of  the  human  operator  is,  of  course,  that  of  truck  driver.  In 

this  example  one  of  the  tasks  of  the  operator  is  to  control  the  operation 
of  the  truck  engine.  A  subtask  necessary  to  do  this  would  be  to  start  the 
engine.  A  task  element  of  this  subtask  would  be  to  Insert  the  key  into  its 
slot.  Another  task  element  would  be: 

(1)  Engaging  the  gas  pedal.  Turn  to  Page  47. 

(2)  Turning  the  key  to  the  right.  Turn  to  Page  9. 

(3)  Driving  the  truck.  Turn  to  Page  92. 

(4)  All  of  these  are  task  elements.  Turn  to  Page  99. 


(3)  Did  you  skip  the  first  20  lessons?  In  those  lessons  we  noted  that  man 
cannot  always  physically  adjust  to,  and  should  not  have  to  operate,  equip¬ 
ment  which  has  not  been  properly  human  engineered.  Return  to  Page  43. 
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(3)  We  hope  you  are  kidding  with  this  choice.  After  all,  you  just  learned 
about  an  acquisition  phase  which  follows  the  full-scale  development  phase. 
Try,  try  again  on  Page  41. 
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From  Page  35 


(1)  Correct.  This  statement  Is  not  a  good  example  of  a  proper  action  state¬ 
ment,  because  It  really  doesn't  tell  the  Job  incumbent  what  to  do.  It  seems 
to  be  relating  or  speaking  to  someone  else  and  to  be  stating  future  objec¬ 
tives.  The  proper  format  would  have  been  'name  the  parts  of  the  lawn 
mower . ' 


Let's  try  another  one.  Which  of  the  following  SBOs  Is  correct? 

(1)  Step  on  the  clutch  before  engaging  the  gear  shift  level.  Turn  to  Page 
92. 

(2)  Given  an  operator's  manual  and  the  associated  radar  equipment,  the 
trainee  will  familiarize  himself  with  it.  Turn  to  Page  89. 

(3)  Given  a  compass  and  a  map,  lead  a  squad  of  men  from  point  'A'  as  shown 
on  that  map,  to  point  'B'  in  30  minutes,  with  no  more  than  two  false  turns. 
Turn  to  Page  68. 

(4)  All  of  these  are  correct.  Turn  to  Page  20. 


From  Page  83 


(^)  Task  analysis  is  performed  to  analyze  human  behaviors,  not  equipment. 
Return  to  Page  83  and  try  again. 


From  Page  46 


(3)  The  lack  of  a  standard  definition  of  a  task  inventory  isn't  the  most 
pressing  problem.  First,  you  must  know  what  a  task  is.  Return  to  Page  46. 
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From  Page  78 


(4)  Nope,  sorry.  There  are  disadvantages  and  this  Isn't  necessarily  any 
more  of  an  objective  procedure  than  the  other  procedures.  Try  again  on  Page 
78. 


From  Page  56 


(1)  This  Is  In  great  measure  correct  In  concept;  however,  the  constraints 
of  space,  time,  and  especially  cost  tend  to  make  this  notion  an  academic 
one.  Return  to  Page  56. 


From  Page  31 


(3)  Very  good.  You  are  correct. 

The  answer  to  the  previous  question  depends  on  the  output  for  which 
you  are  doing  the  task  analysis.  That  is,  which  one  of  the  task  analysis 
data  Item  descriptions  Is  to  be  used?  At  an  early  phase,  only  very  general 
Information  will  be  available  about  the  system.  Therefore,  you  cannot 
always  go  to  a  detailed  level  of  analysis.  At  a  much  later  phase,  such  as 
production  and  deployment,  a  large  amount  of  detailed  Information  will  be 
available.  In  the  latter  case,  you  nearly  always  can  go  to  a  very  specific 
level  of  detail. 

However,  remember  that  as  soon  as  you  have  a  system  concept  (usually 
toward  the  end  of  the  concept  exploration  phase  of  the  materiel  life- 
cycle),  you  can  construct  a  mock-up,  and  a  careful  analysis  of  the  human 
performance  requirements  will  often  let  you  go  the  task  element  level. 

The  second  question  we  spoke  about  dealt  with  how  to  do  the  sub¬ 
division  or  breakdown.  There  are  at  least  five  procedures  for  doing  the 
breakdown . 

(1)  Perform  the  job. 

(2)  Observe  the  job  being  done  by  someone  else. 

(3)  Interview  those  who  are  experts  on  the  job  content. 

(4)  Examine  existing  documents  about  the  job. 

(5)  Interview  supervisors  of  the  job. 

Each  of  these  procedures  has  its  limitations.  While  we  won't  go  into  a 
theoretical  discussion  of  all  of  them  here,  we  do,  however,  think  it  Is 
necessary  for  an  example  or  two.  Let's  take  the  first  procedure. 

What  Is  a  disadvantage  in  using  the  first  procedure? 

(1)  The  job  often  may  require  more  expertise  than  you  have.  Turn  to  Page 

66. 

(2)  Other  workers  may  be  distracted  by  your  presence.  Turn  to  Page  67. 

(3)  It  Is  not  a  cost-effective  procedure.  Turn  to  Page  99. 

(4)  This  Is  the  most  objective  procedure  and  therefore  has  no  serious  dis¬ 
advantage.  Turn  to  Page  77. 
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From  Page  41 


(4)  Right  on!  Even  when  the  equipment  and  system  are  In  full  operation,  HFE 
continues  to  apply  newly  developed  Information  to  the  system.  We  come  full 
cycle  when  the  new  developments  result  in  a  need  for  a  new  system.  Very 
clever,  keep  up  the  good  work. 

The  kinds  of  Information  that  the  human  factors  engineer  will  be  ex¬ 
pected  to  provide  cover  those  subjects  discussed  in  the  first  20  lessons 
and  more.  In  his  role  in  the  acquisition  cycle,  the  human  factors  engineer 
is  not  limited  to  the  issues  that  we  have  seen  in  these  lessons.  The  human 
factors  engineer  would  be  well  advised  to  be  alert  to  all  sources  of  data 
which  might  affect  his  conclusions  and  recommendations.  Of  particular  im¬ 
portance  are  those  situations  which  relate  to  the  operational  contexts  in 
which  the  system  or  equipment  is  to  be  used  and  the  engineering  character¬ 
istics  of  the  equipment  itself.  One  can  readily  identify  with  the  impor¬ 
tance  of  'user  needs'  in  light  of  the  series  of  fiascos  generated  by  I.  M. 
Eager  as  he  delved  into  an  area  in  which  he  was  unencumbered  by  knowledge 
of  the  human  engineering  issues  at  hand. 

It  is  more  than  a  happy  circumstance  that  some  member  of  the  design 
team  is  familiar  with  the  operational  environment  and  the  problems  of  pro¬ 
spective  users  or  operators  of  the  system  or  equipment  being  designed.  More 
directly,  some  member  of  the  design  team  makes  it  his  business  to  know  what 
the  user  needs  and  expects  the  system  to  do  for  him  and  speaks  for  the  user 
at  the  instant  of  making  design  decisions.  The  HFE  member  of  the  design 
team  is  a  logical  candidate  for  his  duty  because  of  training  and  experi¬ 
ence  . 


You  know  the  areas  of  knowledge  that  a  human  factors  engineer  must 
bring  to  the  acquisition  process.  The  question  now  is,  what  is  his/her 
function  as  a  systems  acquisition  team  member? 

(1)  The  experienced  HFE  will  let  others  take  the  lead  in  blocking  out  sys¬ 
tem  design  and  then  point  out  the  human  factor  considerations  that  need  to 
be  improved  upon.  Turn  to  Page  21. 

(2)  It  is  appropriate  that  the  human  factors  engineer  work  in  an  atmosphere 
of  scientific  detachment.  Turn  to  Page  30. 

(3)  The  HFE  specialist  should  learn  as  much  as  possible  about  all  aspects 
of  the  environments  in  which  the  system  will  operate.  Turn  to  Page  51. 


ii* 


79 


From  Page  43 
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(2)  As  was  discussed  in  earlier  lessons,  some  of  the  current  military  hard¬ 
ware  use  seems  to  support  this  statement.  The  human  factors  engineer  is  not 
supposed  to  get  in  his  licks  after  it  is  too  late  to  change  things.  Regret¬ 
fully,  it  is  often  the  case  that  HFE  program  objectives  are  not.  Indeed, 
being  met.  Return  to  page  43. 


From  Page  4 


(2)  Well,  this  answer  is  partially  correct.  There  is  one  other  major  char¬ 
acteristic  of  human  performance  which  is  Important  and  which  is  used  in 
conjunction  with  accuracy.  Go  to  it  and  try  again.  Return  to  Page  4. 


From  Page  54 


(4)  Somewhat  true.  These  are  all  good  design  principles,  but  only  one  has 
an  obvious  relation  to  transfer  effects.  Return  to  Page  54. 
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From  Page  38 
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(1)  This  Is  a  good  answer,  but  it  doesn’t  fit  the  question.  By  the  time 
contract  specifications  are  developed,  the  expected  performance  capabili¬ 
ties  are  already  recorded  in  some  finite  detail.  Return  to  Page  38. 


From  Page  18 


(2)  Sorry,  but  the  only  function  of  this  system  shown  above  is  to  drive  the 
truck.  Try  again  on  Page  18. 


From  Page  25 


(2)  That  is  not  correct.  In  stage  one  you  are  working  only  with  the  criti¬ 
cal  tasks  of  a  job  (selected  from  the  task  inventory),  not  every  task. 
Also,  you  may  not  be  interested  in  a  task  element  if  it  is  at  too  detailed 
a  level.  Return  to  Page  25  and  try  again. 
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From  Page  90 


(2)  Very  good.  Historically,  a  common  error  has  been  to  omit  task  analysis 
at  this  phase.  However,  it  makes  sense  to  analyze  the  tasks  as  much  as  pos¬ 
sible  in  the  early  stages  of  design  so  that  errors  can  be  avoided.  It  is 
also  very  important  to  remember  to  start  early.  But  in  each  successive 
phase,  the  analysis  should  be  updated  (as  more  detailed  design  occurs). 

That  last  question  is  an  important  one.  It  reinforces  the  current  be¬ 
lief  among  human  factors  engineers  that  task  analysis  can  and  should  be 
conducted  early  in  system  development.  Waiting  until  later  phases,  espe¬ 
cially  the  mock-up  or  test  and  evaluation  phases,  is  too  late  to  be  cost 
effective.  As  our  example  points  out,  waiting  until  the  system  is  operable 
can  be  dangerous.  Early  design  deficiencies,  especially  those  influencing 
human  performance  requirements  in  the  system,  may  remain  unnoticed  until 
late  development  phases,  or  even  until  the  system  is  operating  in  the 
field,  as  in  the  real-life  case  history.  This  means  that  the  task  analysis 
process  needs  to  be  applied  at  the  earliest  stage  of  system  design  and  at 
subsequent  developmental  stages  of  the  system  as  well.  Task  analysis  for 
design  will  also  provide  a  source  of  information  for  evaluators  to  assess 
the  extent  to  which  system  design  requirements  affect  human  performance 
requirements.  But,  design  is  not  the  only  reason  for  task  analysis.  Task 
analysis  also  discloses  important  information  concerning  the  personnel 
skills  needed  and' the  length  and  cast  of  the  training  program. 

Now,  let's  talk  about  task  analysis  for  training.  Task  analysis  for 
training  needs  to  take  into  account  four  considerations: 

(1)  The  target  population. 

(2)  Training  materials,  devices,  and  testing  that  will  be  developed 
from  the  output  of  a  task  analysis. 

(3)  A  definition  of  effective  job  performance  of  operators  and  main- 
tainers  which  should  result  from  training. 

(4)  Assessment  of  the  training  requirements  of  the  system. 

Therefore,  when  you  perform  a  task  analysis  for  training  and  take  into 
account  these  four  considerations,  they  will  influence  which  data  you  col¬ 
lect,  how  you  collect  it,  and  how  you  organize  it.  The  output  of  the  task 
analysis  will  then  be  of  the  greatest  use  for  application  to  training 
needs.  Different  methods  (processes)  exist  for  doing  task  analysis,  and  it 
is  not  a  case  of  one  method  or  process  being  best.  All  of  them  employ  the 
same  theoretical  principles:  break  down  the  job  into  the  smallest  element 
feasible;  do  the  breakdown  in  a  systematic  way;  gather  Information  relevant 

(Go  on  to  the  next  page) 


82 


From  Page  82 


iJ 


to  the  task  analysis  purpose  as  the  breakdown  is  being  done;  be  as  rigor¬ 
ous,  quantitative,  and  objective  as  possible  throughout  the  process. 
Specifically,  the  task  analysis  for  training  provides  a  description  of: 

(1)  Each  operator  task  required. 

(2)  Each  maintenance  task  required. 

The  information  provided  in  each  of  these  descriptions  should  include: 

(1)  Task  and  subtask  descriptions. 

(2)  Any  HF  considerations  such  as  environmental  conditions. 

(3)  Listing  of  equipment  or  tools  required  for  each  specific  subtask. 

From  this  type  of  Information,  you  will  also  provide  data  necessary 
for  the  development  of  training  materials,  devices,  and  the  qualitative/ 
quantitative  standards  of  performance. 

Test  and  evaluation  is  next.  But  first ...  answer  the  following  ques¬ 
tion.  Which  of  the  answers  best  describes  what  task  analysis  and  test  and 
evaluation  are  all  about? 

(1)  None  of  these  is  100  percent  correct.  Turn  to  Page  44. 

(2)  Task  analysis  done  during  this  phase  (test  and  evaluation)  determines 
whether  or  not  the  hardware  and  software  can  perform  the  assigned  tasks. 
Turn  to  Page  76. 

(3)  Task  analysis  done  during  the  test  and  evaluation  phase  determines  the 
proficiency  levels  needed  by  the  equipment.  Turn  to  Page  91. 

(4)  The  test  and  evaluation  phase  seeks  to  assess  the  effect  of  equipment 
performance  and  system  performance.  Turn  to  Page  34. 

(5)  All  of  these  answers  are  correct.  Turn  to  Page  57. 


From  Page  56 


(2)  There  is  much  truth  to  this  statement;  however,  resolving  the  trade-off 
issue  is  a  give  and  take  (not  an  act-and-react)  process.  Return  to  Page 
56. 
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From  Page  54 


(1)  Beautiful!  You  got  It  right.  One  task  Inventory  can  serve  several  pur¬ 
poses. 

In  your  supplement,  Figure  23.1  summarizes  what  we  have  discussed  so 
far.  Task  analysis  Is  depicted  as  a  process,  not  as  a  static  variable.  Why 
is  this  so? 

(1)  Because  once  the  task  analysis  information  is  applied  to  the  output 
categories  the  process  stops.  Turn  to  Page  12. 

(2)  Because  the  information  contained  in  the  input  is  used  in  the  task 
analysis.  Turn  to  Page  2. 

(3)  Because  the  output  from  task  analysis  can  be  used  to  add  to  task  inven¬ 
tories  or  supporting  data.  Turn  to  Page  45. 

(4)  All  of  these  answers  are  correct.  Turn  to  Page  39. 


From  Page  52 


(1)  Yes,  the  mock-up  can  really  help  the  human  factors  engineer  in  doing 
his  job  well,  but  these  reasons  are  not  the  only  ones.  Try  again.  Return 
to  Page  52. 


From  Page  46 


(4)  Lack  of  a  uniform  may  be  super  important  (if  not  downright  embarras¬ 
sing),  but  how  does  this  apply  to  task  analysis?  Humorous  answers  are 
usually  not  correct,  but  they  are  fun.  Keep  plugging.  Return  to  Page  46. 
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I  (4)  Absolutely  correct.  At  this  point  In  systems  analysis,  we  don't  want  to 

make  design  constraints.  Eventually,  the  design  team  will  determine  which 
|  functions  are  allocated  to  the  human  and  which  functions  are  to  be  per- 

j  formed  by  machines.  Then,  we  will  determine  the  human  performance  require¬ 

ments, 
v 

In  the  Initial  stages  of  systems  design,  we  want  to  paint  with  a  broad 
brush,  so  to  speak.  Using  resources  such  as  HFTEMAN  and  HEDGE  will  provide 
i  you  with  the  broad  categories  or  templates  of  system  functions.  These  broad 

categories  Include  such  functions  as: 

(1)  Command  and  control 

(2)  Communications 

(3)  Transportation 

There  are,  of  course,  several  other  categories  contained  in  these 
documents  and  you  are  not  limited  by  just  these  templates.  If  new  functions 
appear,  of  course,  you  Include  them.  Oh,  by  the  way,  we  know  you  may  not  be 
familiar  with  the  documents  just  mentioned  (HFTEMAN,  HEDGE).  Don't  worry. 
Later  In  this  course  (Lesson  37)  you  will  learn  about  them  In  some  detail. 

Let's  continue  with  the  analysis  of  the  system.  So  far  we  have  defined 
the  missions)  of  the  system  and  determined  the  functions  which  are  re¬ 
quired  in  order  for  the  mission  to  be  accomplished.  The  next  step  Is  to 
decompose  these  functions  Into  tasks.  You  have  to  have  a  reasonable  idea  of 
what  the  human  must  do  within  the  system  before  you  can  determine  human 
performance  specifications. 

Task  analysis  Is  the  subject  material  of  your  next  two  lessons.  There- 
fore,  you  will  only  have  a  short  section  in  this  lesson.  Generally  speak¬ 
ing,  task  analysis  is  a  systematic  analysis  of  each  function.  After  each 
function  has  been  analyzed,  you  should  have  an  enumeration  of  all  the 
activities  required  to  perform  the  functions. 

Which  of  the  following  statements  Is  a  task  required  of  one  of  Eager's 
helicopter  crew? 

( 

(1)  Plot  flight  path.  Turn  to  Page  4. 

(  (2)  Orbit  earth.  Turn  to  Page  65. 

.  (3)  Fly  at  supersonic  speeds.  Turn  to  Page  97. 

(4)  Maintain  Interstellar  peace.  Turn  to  Page  17. 

( 
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(4)  Good  show.  You're  absolutely  right.  Every  one  of  these  answers  Is  a 
legitimate  performance  requirement  of  the  mission. 

We  hope  this  last  question  helped  you  see  that  numerous  operational 
performance  requirements  may  be  needed  to  satisfy  a  single  mission  objec¬ 
tive.  The  purpose  of  analyzing  system  requirements  and  constraints  Is  to 
Identify  the  specific  functions  that  must  be  performed  by  the  system  to 
meet  those  objectives.  Thus,  requirements  analysis  builds  the  foundation  on 
which  the  human  factors  specialist  can  begin  the  description  of  system 
functions.  Functions  are  the  most  general  means  whereby  system  requirements 
are  met  or  satisfied.  Function  analysis  Is  usually  performed  within  the 
context  of  mission  segments  or  particular  objectives.  Functions  include 
such  things  as  monitoring,  controlling,  or  processing  Information.  Identi¬ 
fication,  analysis,  and  synthesis  of  system  functions  comprise  the  step 
that  translates  system  requirements  and  constraints  Into  an  organized  pro¬ 
gram  for  implementation  of  design. 

Before  we  go  on  (and  confuse  you),  let's  pause  and  review  what  we've 
said  thus  far.  You  have  been  given  a  general  review  of  the  five  general 
purposes  of  systems  analysis:  scheduling,  identifying  limiting  factors, 
establishing  performance  criteria,  identifying  and  explaining  various 
design  options,  and  evaluating  systems. 

So  far,  our  discussion  has  been  focused  on  the  system  and  not  espe¬ 
cially  on  the  human.  In  the  past,  the  HFE  contribution  to  systems  analysis 
has  been  stated  in  equipment  terms.  Previously,  government  HFE  specialists 
were  tasked  with  specifying  'design'  requirements.  These  specifications  are 
still  important  and  required.  Information  dealing  with  work  space  design, 
anthropometry,  and  other  issues  you  learned  about  in  your  first  20  lessons 
is  still  necessary  and  important  if  the  human  is  to  interface  with  the 
environment  in  the  best  possible  way. 

Currently,  there  is  a  new  HFE  emphasis  in  systems  analysis.  This  is 
what  0MB  A-109  calls  an  emphasis  on  the  front-end  or  initial  activities  of 
systems  acquisition.  The  current  HFE  emphasis  is  not  spoken  of  in  terms  of 
equipment,  but  rather  in  terms  of  the  mission.  Because  of  the  mission 
orientation,  HFE  specialists  must  now  identify  certain  specifications  which 
are  to  be  included  in  various  materiel  documentation.  Can  you  determine 
what  these  specifications  are? 

(1)  Central-display  compatibility.  Turn  to  Page  21. 

(2)  Human  performance  specifications.  Turn  to  Page  13. 

(3)  Information  processing  requirements.  Turn  of  Page  38. 

(4)  Time  and  error  limitations.  Turn  to  Page  12. 
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From  Page  29 


(3)  You're  right.  The  total  manpower  costs  are  predicted  over  the  life- 
cycle  of  the  system.  That's  hard  to  do  in  an  inflationary  economy. 

Now,  you  are  faced  with  the  problem  of  hundreds  of  pieces  of  perform¬ 
ance  data.  What  do  you  do  with  it  all?  How  do  you  summarize  and  analyze 
all  the  data?  How  can  you  make  sense  out  of  all  this? 

We're  glad  you  asked,  because  we  have  an  answer  winging  through  our 
circuits  to  you  right  now  .... 

Each  piece  of  performance  data  can  be  recorded  and  ranked  with  all  the 
other  pieces.  In  this  way,  you  would  be  able  to  see  the  relative  contribu¬ 
tions  of  each  piece  of  data  to  the  required  objective.  This  process  may  be 
called  a  determination  model.  Such  a  model  should  be  designed  to  be  adapt¬ 
able  to  different  requirements  problems  and  may  typically  be  divided  into 
two  parts:  the  executive  model  and  the  equipment  model.  The  executive  model 
contains  both  the  routine  which  controls  the  computation  of  the  require¬ 
ments  analysis  value  determinations  and  that  routine  which  does  'housekeep¬ 
ing'  chores,  such  as  filing  input  data,  data  management,  and  report  genera¬ 
tion. 


The  equipment  model  contains  cost  equations  permitting  the  estimation 
of  manpower  and  training  life-cycle  costs  associated  with  a  particular 
weapon  system.  Since  each  system  involves  a  unique  set  of  issues  regarding 
trade-off  elements  and  system  design,  the  specifications  of  the  model  will 
vary  with  each  set  of  analyses.  In  general,  however,  there  may  be  standard 
sets  of  equations  for  various  equipment  types.  Therefore,  the  analyst  would 
select  the  appropriate  subset  of  equations  to  support  the  desired  activity 
for  a  specific  analysis.  In  Instances  where  special  concerns  are  being  em¬ 
phasized,  such  as  the  impact  of  the  need  for  a  particular  type  of  support¬ 
ing  facility,  that  emphasis  may  be  highlighted  in  terms  of  related  resource 
costs  by  appropriately  selecting  cost  equations. 

Because  the  executive  model  is  designed  to  accept  numerous  sett  of 
equations  formulated  for  different  sets  of  equipment,  it  can  be  employed  in 
a  wide  range  of  uses  during  the  course  of  system  development.  The  model  may 
support  trade-off  analyses  as  they  become  more  detailed  in  later  stages  of 
the  system  development  cycle.  It  may,  as  well,  assist  in  related  analyses 
affecting  the  introduction  of  the  new  weapons  systems,  such  as  cost/bene¬ 
fit  analysis  or  cost  avoidance  studies  in  support  of  task  analysis. 

Life-cycle  costing  models,  such  as  the  'Army  Life-Cycle  Management 
Model,'  are  invariably  used  during  the  concept  exploration  and  the  demon¬ 
stration  and  validation  phases  when  the  hardware/manpower /human  factors/ 

(Go  on  to  next  page) 
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personnel/tralning  trade-off  studies  are  measured  in  terms  of  dollars.  For 
instance,  during  the  concept  exploration  phase,  the  model  will  be  used  to 
estimate  aggregated  manpower  and  resource  costs  which  may  be  used  as  bench¬ 
marks  in  the  conduct  of  trade-off  analyses.  As  the  system  design  becomes 
more  specifically  defined,  the  resource  estimates  may  be  refined  to  reflect 
greater  levels  of  detail.  Further,  the  model  serves  a  monitoring  function 
by  providing  a  continuous  record  and  a  data  source  for  estimating  resources 
needed  for  future  systems. 

At  the  later  stage  of  development  (just  before  production  and  deploy¬ 
ment),  the  cost  elements  should  be  so  detailed  as  to  permit  identification 
of  costs  with  specific  units  and  installations. 

A  r  mber  of  difficulties  may  arise  in  the  conduct  of  trade-off  stud¬ 
ies.  Two  major  study  design  pitfalls  are  worthy  of  mention. 

The  first  arises  when  the  person  designing  the  study  restricts  the 
range  of  alternatives  or  prejudges  the  merit  of  alternatives.  For  example, 
one  trade-off  might  compare  a  costly  hardware  alternative  with  another 
hardware  alternative,  but  not  with  any  nonhardware  alternatives. 

The  human  factors  engineer’s  knowledge  and  comprehension  of  men  and 
machines  can  provide  strong  assistance  in  this  regard.  Under  the  worst  of 
situations,  an  alternative  may  have  already  been  chosen  and  alternative 
solutions  simply  Investigated  in  order  to  justify  the  preselected  alterna¬ 
tive.  This  approach  to  alternative  selection  might  have  historically  shown 
Itself  to  be  a  good  marketing  technique,  but  it  is  not  relevant  to  the 
production  of  unbiased  trade-off  base  data. 

A  second  problem  in  the  conduct  of  trade-off  analyses  has  to  do  with 
the  credibility  and  confidence  level  of  the  perceived  benefits  in  the  de¬ 
nominator  of  costs/benefits  ratio.  At  the  least,  it  is  difficult  to  derive 
and  define  properly  clear-cut  and  persuasive  benefits  expressed  in  appro¬ 
priate  terms. 

The  three  services  are  now  doing  a  cost/benefit  study  of  HFE  technol¬ 
ogy,  and  we  suggest  that  after  this  lesson  you  secure  a  copy  of  the  follow¬ 
ing  document.  It  will  prove  to  be  an  invaluable  aid  to  your  understanding 
of  the  cost/benefit  process.  The  publication  is  'A  Study  to  Determine  the 
Methodology  for  Measuring  the  Value  of  Human  Factors  in  Military  System 
Development,'  by  Price,  H.E.,  et.al.,  U.S.  Army  Research  Institute  Report, 
1980  (TR-476). 


(Go  on  to  the  next  page) 
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We  have  used  in  our  example  a  'cost  per  unit*  ratio  as  a  measure  of 
benefit.  Under  other  circumstances,  'cost  per  hour  of  effective  operation' 
or  'cost  per  adequately  trained  man'  may  be  equally  as  valid.  The  point  is 
that  the  relative  merit  of  alternatives  must  be  stated  in  terms  which  are 
clearly  descriptive  of  how  the  system  will  satisfy  requirements.  Only  when 
this  type  of  quantification  is  made  is  there  a  full  confidence  that  re¬ 
sources  are  being  expended  In  the  best  possible  way. 

Since  this  lesson  has  emphasized  measuring  cost/benefits  in  terms  of 
dollars,  can  we  conclude  that  trade-off  studies  are  just  a  way  of  finding 
the  cheapest  way  to  do  a  thing? 

(1)  Emphasis  on  dollar  costs  in  trade-off  studies  is  stressed  simply  be¬ 
cause  it  is  a  convenient  way  to  keep  score  and  can  be  used  to  place  values 
on  all  alternatives.  Turn  to  Page  92. 

(2)  There  is  much  truth  in  this  conclusion.  However,  trade-off  decisions 
often  must  weigh  measures  of  goodness  that  cannot  be  expressed  in  terms  of 
dollars.  Turn  to  Page  91. 

(3)  In  terms  of  defense,  we  must  always  select  the  highest  of  equipment 
capabilities.  Trade-offs  help  us  to  find  that  best  system  and  put  a  price 
tag  on  it.  Turn  to  Page  25. 


From  Page  76 


(2)  There  are  at  least  three  major  reasons  why  this  SBO  is  not  correct.  The 
action  verb  does  not  require  actual  performance  and  it  is  vague.  The  SBO 
does  not  have  a  specific  object  (i.e.,  the  word  'it'  could  refer  either  to 
the  manual  or  to  the  radar,  making  it  ambiguous).  Finally,  the:e  is  no 
standard  of  performance.  Return  to  Page  76  and  try  again. 
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(1)  Very  good.  The  primary  reason  for  using  population  stereotypes  is  to 
ensure  positive  transfer  effects  and  prevent  negative  transfer. 

Task  analysis  is  the  one  common  technique  used  by  all  five  areas  of 
HFE — design,  training,  test  and  evaluation,  manning,  and  workload.  The  new 
DIDS,  approved  January  1980,  relate  to  task  analysis  in  each  HFE  area. 

The  description  and  purpose  sections  of  these  new  DIDS  have  been  in¬ 
cluded  in  your  supplement  on  pages  61  to  64.  After  you  complete  this  les¬ 
son,  we  suggest  that  you  read  these  pages  to  increase  your  knowledge  of 
task  analysis. 

Task  analysis  for  design  of  hardware  and  software  configurations  takes 
into  account  the  capabilities  and  limitations  of  the  target  population 
(system  operators  and  maintainers)  and  human  engineering  principles.  Since 
we  are  discussing  the  design  outcome  of  task  analysis,  let's  step  back  a 
moment  and  recall  the  various  phases  in  system  development.  These  phases 
are: 


(1)  Mission  area  analysis — statements  as  to  the  mission  of  the  system, 
stages  of  mission  execution,  and  so  on. 

(2)  Concept  exploration — assigning  functions  to  the  human  operator, 
determining  the  number  of  personnel  needed. 

(3)  Demonstration  and  validation  through  full-scale  development,  how 
the  instruments  can  be  simplified,  how  configuration  changes  will  affect 
the  human. 

(4)  Production  and  deployment — preparation  of  final  quantitative  and 
qualitative  personnel  requirements  information  (QQPRI)  and  MOS  decision, 
aware  of  contract  for  full-scale  production. 

At  what  point  in  the  design  phases  should  task  analysis  be  applied? 

(1)  At  Phase  Two,  because  that  is  the  time  when  functions  are  assigned. 
Turn  to  Page  14. 

(2)  At  Phase  One,  even  though  it  is  a  conceptual  phase.  Turn  to  Page  82. 

(3)  At  Phase  Three,  because  then  there  is  at  least  a  prototype.  Turn  to 
Page  17. 

(4)  At  Phase  Four,  because  then  you  have  the  system  in  existence.  Turn  to 
Page  65. 
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(2)  This  answer  is  at  the  heart  of  the  matter.  No  matter  how  well  costs  may 
be  quantified,  some  considerations  may  escape  definition;  the  ultimate  de¬ 
cision  still  must  be  a  human  one. 

In  the  next  lesson  you  will  be  looking  at  a  couple  of  the  key  matters 
that  are  typically  identified  with  the  demonstration  and  validation  phase. 
These  are  reliability  and  maintainability.  It  is  obvious  that  here  there  is 
input  data  for  trade-off  analysis.  Let's  get  together  again  soon  to  see  how 
these  issues  are  viewed  by  human  factors  specialists. 


From  Page  83 


(3)  Task  analysis  is  performed  to  analyze  human  behaviors,  not  equipment. 
Return  to  Page  83  and  try  again. 


From  Page  35 


(4)  This  is  a  good  example  of  an  action  statement.  Try  again  on  Page  35 


From  Page  75 


(3)  This  is  the  function.  You  need  to  find  the  smallest  unit  of  behavior  in 
order  to  select  a  task  element.  Return  to  Page  75. 


From  Page  76 


(1)  This  SBO  does  not  contain  any  conditions  for  actions.  Neither  does  it 
have  a  performance  standard.  Return  to  Page  76  and  try  again. 


From  Page  89 


(1)  There  is  a  lot  of  truth  to  this  answer.  However,  although  dollar  costs 
for  benefits  derived  is  at  the  heart  of  all  trade-off  studies,  all  benefits 
cannot  be  expressed  in  dollars.  Return  to  Page  89. 


From  Page  2 


(2)  While  some  portions  of  the  acquisition  process  are  specifically  deline¬ 
ated  by  military  standards,  the  overall  human  factors  need  and  evaluation 
criteria  are  of  necessity  somewhat  broad.  There  is  a  better  answer  here. 
Return  to  Page  2. 
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From  Page  96 


(1)  You're  getting  ahead  of  the  lesson,  but  you  are  right.  Several 
specific-purpose  models  do  exist  to  support  trade-off  analysis  (and  we  will 
look  at  a  couple). 

Estimation  of  manpower  requirements  includes  the  numbers  of  uniformed 
and  civilian  personnel  required  to  operate,  maintain,  and  support  a  par¬ 
ticular  weapon  system  over  its  expected  life.  Included  in  this  estimate  are 
initial  personnel  allocations  and  operating  staffs  as  well  as  the  replace¬ 
ments  necessitated  by  attrition  or  other  types  of  manpower  losses. 

Training  requirements  encompass  estimates  of  the  number  of  training 
personnel  and  assets,  such  as  simulators,  school,  and  devices  needed  to 
provide  for  and  participate  in  training.  Direct  and  indirect  training  man¬ 
power  requirements  are  a  very  important,  yet  often  underestimated,  subset 
of  the  manpower  requirements  of  the  total  system. 

In  estimating  these  'costs,'  a  very  convenient  unit  of  measure  has 
been  found  to  be  the  cost  per  unit.  Cost  estimates  are  initially  made  using 
a  'time  slice'  concept — in  other  words,  time  is  frozen  and  estimates  are 
made  in  constant  value  dollars  without  regard  to  personnel  attrition.  The 
cost  estimate,  as  has  been  explained,  should  include  the  total  number  of 
operation,  maintenance,  and  support  personnel  needed. 

When  the  unit  requirements  have  been  determined,  manpower  costs  can  be 
attained  using  published  or  calculated  dollar  values  assigned  to  various 
grades  and  skills.  In  order  to  reach  a  cost  figure,  the  unit  requirements 
first  must  be  translated  into  military  billets  and  civilian  personnel  re¬ 
quirements. 

The  Important  point  in  determining  the  manpower  and  training  asso¬ 
ciated  with  a  given  alternative  system  is  that  more  than  the  direct  opera¬ 
tion  and  maintenance  costs  are  involved.  Which  of  the  following  statements 
would  you  say  best  defines  the  manpower  parameters  of  an  alternative  system 
cost? 

(1)  A  'time  slice'  of  those  military  and  civilian  personnel  required  to 
operate,  maintain,  support,  and  provide  training  for  the  system  when  the 
planned  number  of  units  is  operational.  Turn  to  Page  5. 

(2)  The  uniformed  personnel  operating  and  maintaining  the  system  plus  an 
appropriate  share  of  those  civilians  responsible  for  providing  support. 
Turn  to  Page  56. 

(3)  The  numbers  of  uniformed  and  civilian  personnel  required  to  operate, 
maintain,  and  support  the  particular  system  over  its  expected  life.  Includ¬ 
ing  initial  crews,  operating  staffs,  and  training  personnel.  Turn  to  Page 
87. 


93 


> 


L 


From  Page  74 


(1)  Very  good.  The  key  element  In  a  trade-off  model  Is  knowledge  of  the 
human  resource  requirement.  The  best  place  to  start  a  trade-off  analysis  Is 
with  what  the  human  must  do. 

While  there  Is  no  one  selection  path  to  answer  all  questions,  there 
can  be  a  valid  general  approach  to  conducting  trade-off  analyses  which  pro¬ 
vides  at  least  a  systematic  procedure  for  considering  trade-offs  among 
hardware  design,  personnel  skill  requirements,  training  requirements,  and 
human  performance  requirements . 

Trade-off  analyses  affecting  manpower  and  training  can  be  conducted 
effectively  during  the  initial  stages  of  systems  development.  It  is  during 
these  early  stages  (concept  exploration  and  demonstration  and  validation) 
that  the  major  portion  of  life-cycle  resources,  such  as  training  and  annual 
operating  costs,  are  committed.  It  is  at  this  phase  that  the  design  deci¬ 
sions  could  be  significantly  improved  as  a  result  of  the  explicit  identi¬ 
fication  of  manpower  versus  hardware  design  trade-offs.  Often,  by  changing 
the  allocation  of  functions  to  human  performance,  significant  changes  can 
be  made  to  personnel  skill  and  training  requirements.  It  is  easy  to  con¬ 
clude  that  the  human  factors  specialist  has  a  key  role  in  this  process. 

• 

There  are  repeated  opportunities  for  trade-off  analyses  to  occur  dur¬ 
ing  the  concept  exploration  and  demonstration  and  validation  phases  of  sys¬ 
tems  development.  The  successive  analyses  are  evolutionary  in  nature  as 
each  round  of  trade-offs  serves  to  refine  previous  conclusions.  The  initial 
analysis,  which  stems  from  the  operational  requirements  analysis,  provides 
the  standard  or  baseline  for  subsequent  analyses,  with  each  building  on 
what  has  gone  before.  Through  this  process,  significant  changes  in  conclu¬ 
sions  can  be  monitored  so  that  changes  in  constraints  can  be  recognized 
early  in  the  development  of  the  systems.  Additionally,  an  'audit  trail'  is 
established. 

Figure  25.2  of  the  student  supplement  summarizes  the  four  major  steps 
included  in  the  trade-off  analysis  of  a  typical  hardware  weapon  system, 
such  as  a  helicopter  or  any  of  its  subsystems. 

The  first  step  involves  defining  a  baseline  alternative  to  which  other 
helicopter  designs  may  be  compared  and  analyzed. 

(Go  on  to  the  next  page) 
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There  are  four  elements  that  provide  a  specification  for  the  baseline 
alternative.  The  first  element  Is  the  operational  requirement.  Initially, 
the  essential  system  characteristics  are  contained  in  the  LOA  (Letter  of 
Agreement).  The  LOA  Is  prepared  jointly  by  the  combat  and  materiel  develop¬ 
ers.  Its  purpose  is  to  ensure  that  both  developers  agree  on  the  general 
nature  of  the  system. 

The  second  element  Is  an  initial  hardware  concept,  which  will  emerge 
based  on  the  operational  requirement.  While  this  concept  will  not  be  a  de¬ 
tailed  specification,  it  does  usually  identify  the  major  subsystems  that 
comprise  the  weapon  and,  thus,  provides  a  basis  for  resource  requirements 
estimation. 

Your  Figure  25.2  suggests  that  the  next  occurring  element  Is  manpower/ 
training  requirements  estimates.  Watch  out!  This  is  one  of  the  most  serious 
errors  in  thinking.  One  must  go  through  the  intermediate  step  of  specifying 
human  performance  requirements  before  rushing  from  hardware  to  personnel 
and  training.  Personnel  and  training  estimates  are  nearly  always  wrong  when 
the  estimator  doesn't  first  bother  to  identify  the  human  performance  re¬ 
quirements. 

Manpower/training  requirements  will  be  used,  finally,  to  make  initial 
estimates  of  life-cycle  costs  for  the  proposed  hardware  design.  These 
initial  cost  estimates  will  be  broad  and  will  undergo  considerable  revision 
during  later  development.  Life-cycle  costs  will  serve  as  one  quantitative 
criterion  for  evaluating  various  alternatives. 

To  give  you  an  idea  as  to  the  ongoing  aspect  of  trade-off  analysis 
step  1,  let  us  say  that  from  the  development  of  the  MENS  to  the  LOA  there 
are  about  three  major  HFE  Inputs  required  in  a  Bystems  acquisition  process. 
From  the  LOA  to  the  ROC  statement  about  30  additional  HFE  inputs  are  made, 
most  of  which  are  a  result  of  trade-off  analyses.  These  and  other  HFE  In¬ 
puts  are  explained  in  the  document  entitled  'Human  Factors  Engineering  in 
Research,  Development  and  Acquisition.'  You  learned  about  this  document  In 
Lesson  21,  remember? 

All  right,  can  you  recall  the  four  elements  needed  to  complete  the 
first  step  of  a  trade-off  study? 

(1)  Personnel,  training,  equipment,  and  human  performance  requirements. 
Turn  to  Page  100. 

(2)  Operational  requirements,  hardware  concepts  and  total  resource  esti¬ 
mates,  manpower  and  software  needs,  and  life-cycle  cost  estimates.  Turn  to 
Page  39. 

(3)  Operational  requirements,  hardward  concept,  resource  estimates,  man¬ 
power  and  training  requirements,  and  life-cycle  costing  estimates.  Turn  to 
Page  24. 
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(1)  That' 8  right.  The  process  Is  repeated  as  many  times  as  it  may  take  to 
Incorporate  all  the  modifications  and  refinements  desired,  with  the  last 
outcome  being  the  starting  point  for  the  next  round  of  analyses. 

It  may  be  concluded  from  earlier  discussions  that  there  are  general 
types  of  computer  models  in  use  to  support  the  more  complex  trade-off 
studies.  The  first  model  typically  is  the  basis  for  determining  manpower 
and  training  requirements.  The  second  model  is  equipment  oriented  and  is 
concerned  with  emphasizing  how  well  the  system  requirements  are  met.  A 
third  model,  the  life-cycle  model,  translates  input  data  into  dollar 
values.  In  order  to  estimate  life-cycle  costs,  you  must  first  know  the 
human  performance  requirements  and  then  estimate  both  manpower  and  training 
requirements . 

Can  all  of  these  variables  that  have  been  mentioned  be  managed  by  de¬ 
signing  an  appropriate  computer-based  model? 

(1)  Yes,  but  the  appropriate  potential  Issues  have  to  be  identified  and 
weighed  before  the  model  can  work.  Thus  far,  general  purpose  models  are 
modified  to  support  specific  trade-off  decisions.  Turn  to  Page  93. 

(2)  So  much  of  this  type  of  analysis  is  subjective,  that  It  practically  by¬ 
passes  the  effective  use  of  a  computer.  Turn  to  Page  34. 

(3)  Yes,  since  the  same  situations  have  been  repeated  time  and  time  again, 
master  programs  are  in  general  use  to  provide  the  best  alternatives .  Turn 
to  Page  39. 


From  Page  41 


(2)  Nope.  Think  a  minute.  Is  HFE  only  concerned  with  the  development  and 
acquisition  of  systems?  There  is  a  better  answer.  Return  to  Page  41. 
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From  Page  24 


(2)  Exactly.  We  are  still  looking  for  the  'biggest  bang  for  a  buck.' 

The  final  step  In  the  trade-off  procedure  Is  to  select  the  preferred 
alternative.  The  analyst's  choice  of  one  of  the  alternatives  could  be  the 
baseline  alternative,  or  one  of  the  others  might  be  found  to  be  preferable. 
In  each  case,  the  selected  alternative  now  becomes  the  new  baseline  for  the 
next  round  of  analyses.  In  our  helicopter  acquisition  example,  for  In¬ 
stance,  the  design  selected  as  a  result  of  trade-off  analyses  done  during 
the  concept  exploration  phaae  will  become  the  baseline  for  analyses  done 
during  the  demonstration  and  validation  phase. 

The  procedure  outlined  in  the  preceding  paragraphs  works,  but  how  well 
it  works  will  depend  on:  How  well  the  criteria  used  to  evaluate.  Alterna¬ 
tives  are  selected;  and  how  clearly  the  relative  merit  of  alternatives  Is 
evaluated . 

Baaed  on  the  foregoing,  which  of  the  following  phrases  best  describes 
the  overall  trade-off  procedure? 

(1)  Iterative  and  evolutionary.  Turn  to  Page  96. 

(2)  Static  and  regressive.  Turn  to  Page  20. 

(3)  Dynamic  and  evolutionary.  Turn  to  Page  32. 


Prom  Page  85 


(3)  Isn't  this  an  example  of  a  function  required  of  the  system  (chopper)? 
Wouldn't  there  be  a  number  of  tasks  to  be  performed  in  order  to  accomplish 
this  function?  Try  again,  please.  Return  to  Page  85. 
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(1)  Even  though  many  things  that  are  in  general  use  can  be  directly  adapted 
to  military  use,  all  potential  procurement  must  be  evaluated  in  the  light 
of  the  overall  environment  in  which  it  will  be  used.  Return  to  Page  2  for 
another  answer. 


From  Page  15 


(1)  This  answer  is  incorrect.  Task  analysis  is  certainly  an  Integral  part 
of  a  systems  analysis,  but  it's  not  the  first  step.  Return  to  Page  15. 


From  Page  74 


(3)  True  enough,  we  have  to  keep  score  under  the  same  rules,  but  prior  to 
that  we  must  decide  what  the  game  will  be  called.  This  is  not  the  answer  we 
are  looking  for.  Return  to  Page  74. 
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(3)  This  is  a  good  answer  as  far  as  it  goes,  but  it  doesn't  encompass  all  ) 

the  key  Issues.  Return  to  Page  24.  ^ 
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From  Page  75 


(4)  Only  one  of  these  Is  a  task  element;  one  Is  a  subtask;  and  one  Is  a 
system  function.  Return  to  Page  75. 


From  Page  78 


(3)  Huh!  If  your  pay  Is  a  fantastic  amount  and  you  spend  a  good  deal  of 
i  time  doing  menial  jobs,  this  might  be  a  good  answer.  However,  It  Isn't  the 

best  one  by  a  long  shot.  Return  to  Page  78. 


1 

t  . 

f 

r 

i 

( 

{ 

{ 

{ 

( 

( 

( 

( 

( 

( 

C 

c 

c 

c 

c 

( 

f 

t 

• 


% 


From  Page  35 


(3)  This  Is  a  good  example  of  an  action  statement.  Try  again  on  Page  35. 


Prom  Page  50 


(4)  If  you  really  think  this  is  the  correct  answer,  you  haven't  understood 
these  last  two  lessons  very  well.  That  is  okay,  because  they  are  difficult, 
but  you  need  to  go  back  over  them  before  proceeding.  Return  to  Page  50. 
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(1)  Ac  this  point,  we  are  beyond  developing  Che  questions  that  need  to  be 
answered  about  operators  and  malntalners;  rather,  we  are  weighing  results 
of  those  questions.  Return  to  Page  16. 


From  Page  15 


(4)  Take  a  closer  look  at  the  model.  Selection  and  development  of  system 
concepts  come  at  the  end  of  the  planning  stage,  not  the  beginning.  Return 
to  Page  15. 


From  Page  74 


(2)  That's  almost  right;  we  can't  start  to  formulate  answers  until  the 
problem  has  been  defined — but  often,  design  of  hardware  can  be  modified  to 
make  the  tasks  easier  for  the  human.  So...  Try  again  on  Page  74. 


From  Page  95 


(1)  These  are  the  four  basis  HFE  considerations,  but  not  the  four  elements 
needed  In  step  1  of  the  trade-off  analysis.  We  are  tempted  to  give  you  half 
credit  for  thinking  HFE,  however.  (Well,  we  can't  give  half  credit,  so 
we'll  suggest  a  pat  on  the  back  Instead.)  Now,  you  need  to  select  the  cor¬ 
rect  answer  as  it  relates  to  Figure  25.2.  Return  to  Page  95. 
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